WO2025241799A1 - Communication method, and apparatus - Google Patents

Abstract

Provided in embodiments of the present application are a communication method and an apparatus. The method comprises: determining a target channel coding type allocated to a terminal, the target channel coding type being determined on the basis of a current service type, communication environment, or service scenario that a network device needs to satisfy, or being determined on the basis of a first channel coding type requested by the terminal on the basis of the current service type or communication environment; and sending downlink indication information to the terminal, the downlink indication information indicating the target channel coding type to be used by the terminal. Thus, variable channel coding based on a service type, communication environment, or service scenario that a network device needs to satisfy can be achieved, thereby providing a more flexible channel coding solution and satisfying requirements on channel coding in various communication scenarios. In addition, the method supports various channel coding types, thus satisfying requirements of more diversified and more harsh communication scenarios.

Description

Communication methods and devices

This application claims priority to Chinese Patent Application No. 202410669780.2, filed on May 24, 2024, entitled "Communication Method and Apparatus", the entire contents of which are incorporated herein by reference.

Technical Field

This application relates to the field of communication technology, and in particular to a communication method and apparatus.

Background Technology

With the development of mobile communication technology, especially the continuous development of new-generation mobile communication technologies such as the fifth-generation mobile networks (5G) and the sixth-generation mobile networks (6G), the functions of communication systems are constantly being enhanced.

The 6G communication system enhances upon the three existing scenarios of 5G communication system: enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (uRLLC), and massive machine-type communication (mMTC). It also adds three new scenarios: artificial intelligence (AI) communication, integrated communication and sensing, and integrated space-ground communication.

Different communication scenarios have different requirements for channel coding. Currently, related technologies mainly determine the encoding method for the data packets to be transmitted based on the encoding parameters of the data packets, such as the size of the data packets, the code rate, or the code length. This approach is insufficient to meet the channel coding requirements of different communication scenarios.

Summary of the Invention

This application provides a communication method and apparatus, which aims to solve the problem that determining the encoding method of the data packet to be transmitted based on the encoding parameters of the data packet to be transmitted is difficult to meet the channel coding requirements of different communication scenarios.

To achieve the above objectives, this application provides the following technical solution:

Firstly, this application provides a communication method. This method can be executed by a network device. A network device is a device on the network side used to provide network communication functions; in some cases, it is also called a network element. A network device can typically be a base station, a functional unit of a base station, or a combination of functional units of a base station. The base station can be any device with wireless transceiver capabilities, including but not limited to evolved base stations in Long Term Evolution (LTE), base stations or transceiver points in New Radio, base stations in subsequent 3GPP evolutions, access nodes in Wi-Fi systems, wireless relay nodes, and wireless backhaul nodes.

Specifically, the network device determines the target channel coding type to be assigned to the terminal. The target channel coding type is determined based on the current service type, communication environment, or service scenario that the network device needs to meet, or it is determined based on the first channel coding type requested by the terminal based on the current service type or communication environment. Then, the network device sends downlink indication information to the terminal, which instructs the terminal to use the target channel coding type.

In this way, variable channel coding can be implemented based on the service type, communication environment, or service scenarios that network equipment needs to meet, providing a more flexible channel coding scheme to meet the channel coding requirements of different communication scenarios.

In some possible implementations, the network device can obtain the current service type, communication environment, or service scenario that the network device needs to meet, and then determine the target channel coding type to be assigned to the terminal based on the mapping relationship between the service type, communication environment, or service scenario and the channel coding type.

In this method, the network side can proactively determine the target channel coding type based on the service type, changes in the communication environment, or the service scenario (such as a vertical service scenario). This allows the network to select a suitable channel coding scheme for the terminal, providing high flexibility and availability.

In some possible implementations, the network device can also receive data sent by the terminal, decode the data using a first error correction code and a second error correction code, and determine whether the target channel coding type is effective on the terminal side based on the decoding result. Here, the first error correction code is the error correction code before sending downlink indication information, and the second error correction code is the error correction code after sending downlink indication information.

This method combines error correction codes before and after sending downlink indication information to decode the uplink data sent by the terminal. Based on the decoding result, it can be determined whether the target channel coding type is effective on the terminal side. When the target channel coding type is effective, the transmission reliability of the terminal and network equipment can be achieved based on the decoding result corresponding to the target channel coding type. Moreover, the network equipment can subsequently transmit downlink data based on the target channel coding type.

In some possible implementations, the network device can also receive feedback information from the terminal, indicating whether the target channel coding type is effective on the terminal side. For example, the terminal can send the feedback information separately or along with data transmission. The network device can quickly determine whether the target channel coding type is effective based on this feedback information, and thus quickly determine the decoding strategy, thereby improving communication efficiency.

In some possible implementations, the network device may also receive uplink request information sent by the terminal, which includes a first channel coding type requested by the terminal based on the current service type or communication environment, and then determine the target channel coding type to be allocated to the terminal based on the first channel coding type.

In this method, the terminal can proactively request the use of a specific channel coding type, such as the first channel coding type, based on the current service type or communication environment. This allows for the selection of a suitable channel coding scheme to meet the needs of diverse communication scenarios.

In some possible implementations, when the resources corresponding to the first channel coding type are sufficient, the network device can determine the first channel coding type as the target channel coding type; when the resources corresponding to the first channel coding type are insufficient, the network device can determine the default second channel coding type or the third channel coding type recommended by the terminal as the target channel coding type.

In some possible implementations, the network device can obtain a set of channel coding types supported by the terminal, and the target channel coding type is determined from this set. This method supports determining the target channel coding type based on different terminal capabilities, and can accurately meet the needs of different types of terminals.

In some possible implementations, the network device may also receive a terminal's registration request or terminal capability response, which includes a set of channel coding types supported by the terminal. By obtaining the set of channel coding types supported by the terminal during registration or capability reporting, the network device can assist in the subsequent allocation of target channel coding types.

In some possible implementations, the channel coding type includes any one or more of low-density parity-check (LDPC) codes, POLAR codes, TURBO codes, convolutional codes or Reed-Solomon codes, and AI module encoding/decoding.

This method supports multiple channel coding types. In addition to the two basic graph types of LDPC codes defined in the 5G standard, it can also support other error correction codes with lower bit error rates and lower decoding latency, including but not limited to POLAR codes, TURBO codes, convolutional codes, or Reed-solomon (RS) codes and AI module encoding and decoding. This can flexibly meet the needs of more diverse and demanding communication scenarios.

Secondly, this application provides a communication method. This method can be executed by a terminal. The terminal can take various forms, such as mobile phones, tablets, computers with wireless transceiver capabilities, virtual reality terminal devices, augmented reality terminal devices, wireless terminals in industrial control, vehicle-mounted terminal devices, wireless terminals in autonomous driving, wireless terminals in telemedicine, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, wearable terminal devices, and so on.

Specifically, the terminal can receive downlink indication information sent by the network device. This downlink indication information indicates the target channel coding type used by the terminal. The target channel coding type is determined based on the current service type, communication environment, or service scenario that the network device needs to meet. Alternatively, the target channel coding type can be determined based on the first channel coding type requested by the terminal based on the current service type or communication environment. Then, the terminal encodes or decodes the data interacting with the network device according to the target channel coding type indicated by the downlink indication information.

In this method, the terminal performs data encoding and decoding according to the target channel coding type indicated by the downlink indication information sent by the network device. This can realize variable channel coding based on service type, communication environment, or service scenarios that the network device needs to meet, providing a more flexible channel coding scheme to meet the channel coding requirements of different communication scenarios.

In some possible implementations, the terminal may report the current service type or communication environment to the network device; or, the terminal may send uplink request information to the network device, the uplink request information including a first channel coding type requested by the terminal based on the current service type or communication environment.

This method supports network devices actively determining the target channel coding type, or terminals actively requesting the first channel coding type. The network device determines the target channel coding type based on the terminal's request, thus providing high availability.

In some possible implementations, the target channel coding type takes effect upon receiving downlink indication information. This allows for rapid encoding and decoding based on the target channel coding type, improving communication efficiency.

In some possible implementations, the terminal can also report a set of channel coding types it supports to the network device, and the target channel coding type is determined from this set. This allows for the determination of different target channel coding types for different types of terminals, thus meeting the needs of various terminal types.

In some possible implementations, the terminal may also send a registration request or a terminal capability response to the network device, which includes a set of channel coding types supported by the terminal. By carrying the set of channel coding types in the registration request or terminal capability response, the terminal provides a reference for subsequent allocation of target channel coding types and can reduce the additional overhead caused by sending the set of channel coding types separately.

In some possible implementations, the channel coding type includes any one or more of LDPC codes, POLAR codes, TURBO codes, convolutional codes or Reed-Solomon codes, and AI module encoding/decoding. This method supports multiple channel coding types, which can flexibly meet the needs of more diverse and demanding communication scenarios.

A third aspect of this application provides a communication device, comprising: a memory and at least one processor. The memory is used to store a program, and the at least one processor is used to run the program, such that the communication device implements the communication method provided in the first or second aspect of this application.

The fourth aspect of this application is a computer storage medium for storing a computer program, which, when executed, is used to implement the communication method provided in the first or second aspect of this application.

Attached Figure Description

Figure 1 shows an example of a communication scenario between a base station and a terminal;

Figure 2 is a flowchart of a communication method disclosed in an embodiment of this application;

Figure 3 is a flowchart of another communication method disclosed in an embodiment of this application;

Figure 4 is an interactive flowchart of a communication method disclosed in an embodiment of this application;

Figure 5 is an interactive flowchart of another communication method disclosed in an embodiment of this application;

Figure 6 is a structural example diagram of a communication device disclosed in an embodiment of this application;

Figure 7 is a structural example diagram of another communication device disclosed in an embodiment of this application.

Detailed Implementation

The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. 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. As used in the specification and appended claims of this application, the singular expressions "a," "an," "the," "the," "the," and "this" are intended to also include expressions such as "one or more," unless the context clearly indicates otherwise. It should also be understood that in the embodiments of this application, "one or more" refers to one, two, or more; "and/or" describes the relationship between related objects, indicating that three relationships may exist; for example, A and/or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character "/" generally indicates that the preceding and following related objects are in an "or" relationship.

References to "one embodiment" or "some embodiments" as described in this specification 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.

The "multiple" mentioned in the embodiments of this application refers to two or more. It should be noted that in the description of the embodiments of this application, terms such as "first" and "second" are used only for the purpose of distinguishing descriptions and should not be construed as indicating or implying relative importance, nor should they be construed as indicating or implying order.

The embodiments of this application are applied to communication systems, which can be second-generation (2G) communication systems, third-generation (3G) communication systems, LTE systems, fifth-generation (5G) communication systems, LTE and 5G hybrid architectures, 5G New Radio (5G NR) systems, sixth-generation (6G) communication systems, and new communication systems that will emerge in the future development of communication.

The aforementioned communication systems can be used in different communication scenarios to meet the needs of those scenarios. For example, 5G communication systems primarily meet the needs of three major scenarios: enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (uRLLC), and massive machine-type communication (mMTC). In addition to enhancing the three scenarios applicable to 5G communication systems, 6G communication systems also add three other scenarios: artificial intelligence (AI) communication, integrated sensing and communication (ISAC), and space-ground integrated (SGI).

AI communication refers to integrating AI technology into communication networks to achieve network intelligence. Taking wireless access networks as an example, AI can improve the accuracy and efficiency of signal processing, as well as automate and optimize network operations. For instance, deep learning and reinforcement learning algorithms can be used to evaluate and predict channel quality, and improve signal detection and channel coding/decoding.

Communication-sensing integration specifically involves integrating sensing capabilities (such as general sensing capabilities beyond positioning) into a communication system. These general sensing capabilities can include those provided by devices such as conventional radar, lidar, computed tomography (CT), and magnetic resonance imaging (MRI). Integrating these capabilities into a communication system enables high-precision positioning, tracking, biomedical and security imaging, simultaneous positioning and mapping for complex indoor and outdoor environments, pollution and natural disaster monitoring, gesture and motion recognition, and defect and material detection.

Space-ground integration refers to the networking technology that interconnects the space-based backbone network, space-based access network, and ground-based node network with the terrestrial Internet and mobile communication network to build a space-ground integrated information network system with "global coverage, ubiquitous access, on-demand service, and security and reliability".

A communication system includes network equipment and terminals. Network equipment is the device on the network side used to provide network communication functions; it is sometimes also called a network element. Network equipment can typically be a base station, a functional unit of a base station, or a combination of functional units of a base station. An example of a communication system is shown in Figure 1, which includes base station 1 and terminal 2.

In the embodiments provided in this application, the base station can be any device with wireless transceiver capabilities, including but not limited to: evolved base stations (NodeB, eNB, or e-NodeB) in Long Term Evolution (LTE), base stations (gNodeB or gNB) or transmission receiving points/transmission reception points (TRPs) in New Radio (NR), base stations in subsequent 3GPP evolutions, access nodes, wireless relay nodes, wireless backhaul nodes, etc., in Wi-Fi systems. The base station can be: macro base station, micro base station, pico base station, small cell, relay station, or balloon station, etc. The base station can include one or more co-located or non-co-located transmission reception points (TRPs). The base station can also be a radio controller, centralized unit (CU), and/or distributed unit (DU) in a cloud radio access network (CRAN) scenario. Base stations can communicate with terminals directly, or they can communicate with terminals via relay stations. Terminals can communicate with multiple base stations using different technologies. For example, a terminal can communicate with a base station that supports LTE networks, or it can communicate with a base station that supports 5G networks, or it can establish dual connections with both LTE and 5G base stations.

In the embodiments provided in this application, the terminal can be of various forms, such as a mobile phone, tablet computer, computer with wireless transceiver capabilities, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal in industrial control, vehicle-mounted terminal device, wireless terminal in self-driving, wireless terminal in remote medical, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, wearable terminal device, etc. The terminal may also be referred to as a terminal device, user equipment (UE), access terminal device, vehicle-mounted terminal, industrial control terminal, UE unit, UE station, mobile station, mobile station, remote station, remote terminal device, mobile device, UE terminal device, terminal device, wireless communication device, UE agent, or UE device, etc. The terminal can also be a fixed terminal or a mobile terminal.

Communication systems typically require channel coding during communication. Different communication scenarios have different requirements for channel coding. For example, in future immersive communication scenarios requiring eMBB, the real-time transmission of 3D high-definition video and even holographic images requires channel coding with higher bit rates and lower decoding latency. In future remote surgery scenarios requiring uRLLC, deterministic control of mechanical scalpels requires channel coding with lower bit error rates. In future integrated space-ground systems, more interference-resistant channel coding is needed. Furthermore, in channel state information (CSI) feedback, the more bits of information fed back, the higher the feedback accuracy; therefore, higher bit rate channel coding is required. In Hybrid Automatic Repeat Request Acknowledge (HARQ-ACK) feedback, fast retransmission is required, thus necessitating channel coding with shorter decoding latency.

Currently, the widely used channel coding schemes in the industry determine the encoding method for the data packets to be transmitted based on the encoding parameters of the data packets, such as the size of the data packets, the code rate, or the code length. This method does not consider the different channel coding requirements of various communication scenarios, thus making it difficult to meet the channel coding requirements of different communication scenarios.

In view of this, this application provides a communication method. In this method, a network device can determine the target channel coding type to be allocated to a terminal, specifically based on the current service type, communication environment, or service scenario that the network device needs to meet (e.g., a vertical service scenario), or based on a first channel coding type requested by the terminal based on the current service type and communication environment. Then, the network device sends downlink indication information to the terminal, which instructs the terminal to use the target channel coding type.

In this way, variable channel coding can be implemented based on service type, communication environment, or network equipment requirements, providing a more flexible channel coding scheme to meet the channel coding requirements of different communication scenarios. Moreover, this method supports multiple channel coding types. In addition to the two base graph (BG) types of low-density parity-check (LDPC) codes defined in the 5G standard, it can also support other error-correcting codes with lower bit error rates and lower decoding latency, including but not limited to POLAR codes, TURBO codes, convolutional codes, Reed-Solomon (RS) codes, and AI module encoding/decoding. This allows for flexible fulfillment of the needs of more diverse and demanding communication scenarios.

To make the technical solution of this application clearer and easier to understand, the communication method of this application will be introduced from the perspective of network devices first.

Referring to the flowchart of a communication method shown in Figure 2, the method includes the following steps:

S202, The network device determines the target channel coding type assigned to the terminal.

Channel coding, also known as error control coding, involves adding redundant information to the original data at the transmitting end. This redundant information is correlated with the original data, and the receiving end uses this correlation to detect and correct errors that occur during transmission, thereby combating interference during transmission.

The communication system described in this application can support multiple channel coding types. Specifically, the channel coding type can include any one or more of LDPC codes, POLAR codes, TURBO codes, convolutional codes or Reed-Solomon codes, and AI module encoding/decoding. Relevant standards define two BG types for LDPC codes: BG1 and BG2. BG1 has a larger matrix and supports a maximum code block length of 8448 bits, while BG2 has a smaller matrix and supports a maximum code block length of 3840 bits. It should be noted that BG1 and BG2 are primarily used to meet the needs of eMBB, uRLLC, and mMTC scenarios. To meet the needs of more diverse and demanding communication scenarios, some institutions or organizations have proposed LDPC codes with lower bit error rates and lower decoding latency, based on relevant standard error correction codes. LDPC codes employ an efficient parallel decoding architecture, and the decoder for LDPC codes has advantages in terms of hardware implementation complexity and power consumption. POLAR codes offer both low encoding and decoding complexity and a low error rate. They also support flexible code lengths and rates, resulting in good performance. TURBO code decoders consist of two component decoders, with decoding iteratively occurring between them to address computational complexity. Convolutional code decoding not only extracts decoding information from the current code group but also reuses code groups received before and after iteratively, extracting relevant decoding information from these conditions. Furthermore, decoding is continuous, ensuring relatively low decoding latency. Reed-Solomon codes (RS codes) are a type of forward error-correcting channel coding that uses valid polynomials generated from corrected oversampled data. The encoding process first redundancy these polynomials at multiple points before transmitting or storing them. AI module encoding and decoding specifically refers to the end-to-end encoding or decoding of data input into an AI model.

The target channel coding type can be one or more of the channel coding types supported by the communication system. The network device can proactively determine the target channel coding type assigned to the terminal, whereby the target channel coding type is determined based on the current service type, communication environment, or vertical service scenario that the network device needs to meet. Alternatively, the terminal can proactively request the allocation of a first channel coding type based on the current service type or communication environment, and the network device can determine the target channel coding type assigned to the terminal based on the terminal's request. The specific implementation of determining the target channel coding type is described in detail below.

In some possible implementations, the network device can obtain the current service type, communication environment, or service scenario that the network device needs to meet, and then determine the target channel coding type to be assigned to the terminal based on the mapping relationship between the service type, communication environment, or service scenario and the channel coding type.

The business types can include the data plane, user plane, control plane, intelligence plane, or security plane. The different functional planes are explained below.

The control plane enables unified control of network connectivity services, intelligent services, computing power services, and perception services. As the center of network control, the control plane collaborates with other layers to complete integrated management and control functions such as multi-access convergence control, authentication and authorization, mobility management, session management, policy control, AI task scheduling, operator resource allocation and management.

The user plane supports network programmability, allowing for flexible definition of data processing and measurement. Specific functions may include tunnel management, data flow identification, service awareness, deterministic communication assurance, data encapsulation, data forwarding, and traffic routing. The user plane primarily handles the transmission of user session data. Furthermore, in next-generation communication systems, the user plane can also process and forward various data, such as environmental object perception data and AI task data.

The data plane is used to further separate data from business logic, reducing the tight coupling between data and business processing. Introducing a separate data plane into the network enables unified management of data, and the data plane is exposed to the control plane, user plane, intelligence plane, and security plane through standard interfaces.

The intelligent plane is the intelligent hub of the network, supporting comprehensive intelligence in both the core and access networks. It serves as the carrier for intelligent services, providing local AI capabilities to service recipients and global AI capabilities through the collaboration of distributed intelligent nodes. The AI capabilities provided can include, but are not limited to, data modeling, model training, inference and decision-making, knowledge graphs, feedback, and evaluation.

The security aspect leverages "security data and AI" to drive security awareness and proactive protection, building a zero-trust security system and achieving "intrinsic security." "Intrinsic security" refers to assigning appropriate security attributes to each stage of the software development lifecycle—from requirements, design, development, testing, building, release, and operation—and ensuring these attributes work in tandem to create a multiplier effect, effectively guaranteeing software product security.

The communication environment can be indicated by signal strength. For example, a signal strength greater than a signal strength threshold indicates a good signal environment, including but not limited to the ground and outside elevators; a signal strength less than the signal strength threshold indicates a poor signal environment, including but not limited to underground parking garages and inside elevators.

A business scenario can be a summary of a user's behavior or activities in a specific environment. Within this, a business scenario can be a vertical business scenario. A vertical business is a business formed by horizontally assembling various horizontal businesses according to certain rules. Horizontal businesses can be packaged into components, and vertical businesses can be obtained by orchestrating the processes of these horizontal business components. For example, vertical business scenarios can include those in vertical industries such as autonomous transportation, digital energy, intelligent manufacturing, telemedicine, and smart agriculture, including but not limited to remote surgery scenarios.

The mapping relationship between service type, communication environment, or service scenario and channel coding type can be agreed upon in the protocol, pre-configured by the user, or negotiated between network equipment and the terminal. For example, the protocol may stipulate that the channel coding type corresponding to the data plane includes at least one of LDPC code or POLAR code.

Network devices can sense service types, communication environments (e.g., changes in the communication environment), or service scenarios that the network device needs to meet. Based on the sensing results, they can query the mapping relationship between service types, communication environments, or service scenarios and channel coding types to determine the target channel coding type. The sensing methods can include various approaches: one is measurement and sensing by the network device itself; another is reporting by the terminal, such as the terminal reporting the service type or communication environment; and yet another is notification from a third-party network element or cooperating node to the network device.

In some other possible implementations, the network device can receive uplink request information sent by the terminal. This uplink request information includes a first channel coding type requested by the terminal based on the current service type or communication environment. Accordingly, the network device can determine the target channel coding type to allocate to the terminal based on the first channel coding type.

The methods for a terminal to request a first channel coding type and for the network device to determine a target channel coding type are as follows: The terminal can determine the first channel coding type by querying the mapping relationship between the service type, communication environment, or service scenario and the channel coding type, based on the current service type or communication environment. The network device can decide on the target channel coding type to allocate to the terminal based on resource usage. For example, if resources for the first channel coding type are sufficient, the network device can allocate the first channel coding type to the terminal. Conversely, if resources for the first channel coding type are insufficient, the network device can allocate a second or third channel coding type to the terminal. Specifically, the network device can determine the target channel coding type as either the default second channel coding type or the third channel coding type recommended for the terminal.

When recommending channel coding types, network devices can recommend a third channel coding type to the terminal based on the resource usage corresponding to the channel coding type and the set of channel coding types supported by the terminal. The third channel coding type can be one or more channel coding types from the set of channel coding types. The network device can determine the third channel coding type from the set of channel coding types based on resource usage and through load balancing strategies.

In some possible implementations, the network device can obtain a set of channel coding types supported by the terminal. For example, the network device can receive a registration request or a UE capability response from the terminal. The registration request or UE capability response includes a set of channel coding types supported by the terminal. The target channel coding type can be determined from the aforementioned set of channel coding types.

S204. The network device sends downlink instruction information to the terminal.

The downlink indication information indicates to the terminal the target channel coding type. This downlink indication information may include downlink control information (DCI), or other downlink indication information in next-generation communication systems; this embodiment does not impose any limitations on this.

In some possible implementations, the network device can also receive data sent by the terminal, such as uplink data. The network device can decode the data using a first error correction code and a second error correction code, and determine whether the target channel coding type is effective on the terminal side based on the decoding result. The first error correction code is used before sending downlink indication information, and the second error correction code is used after sending downlink indication information.

In other possible implementations, the network device may also receive feedback information from the terminal, indicating whether the target channel coding type is effective on the terminal side. When the target channel coding type is effective on the terminal side, the network device can use a decoder corresponding to the target channel coding type for decoding.

Based on the above description, this application provides a communication method. This method can implement variable channel coding based on service type, communication environment, or the service scenarios required by network equipment, providing a more flexible channel coding scheme to meet the channel coding requirements of different communication scenarios. Furthermore, this method supports multiple channel coding types, thereby flexibly meeting the needs of more diverse and demanding communication scenarios.

The communication method of this application has been described above from the perspective of network devices. The following section describes the communication method of this application from the perspective of the terminal.

Referring to the flowchart of a communication method shown in Figure 3, the method includes the following steps:

S302. The terminal receives downlink instruction information sent by the network device.

The downlink indication information indicates the target channel coding type used by the terminal. The target channel coding type can be one or more of the channel coding types supported by the communication system, which may include any one or more of LDPC codes, POLAR codes, TURBO codes, convolutional codes, or Reed-Solomon codes.

The target channel coding type can be determined based on the current service type, communication environment, or service scenario that the network device needs to meet. For example, the network device can actively determine the target channel coding type based on the current service type, communication environment, or vertical service scenario that the network device needs to meet. Alternatively, the target channel coding type can be determined based on the first channel coding type requested by the terminal based on the current service type or communication environment.

In some possible implementations, the terminal can report its current service type or communication environment to the network device. In this way, the network device can determine the target channel coding type based on the reported service type or communication environment. It should be noted that the network device can also determine the target channel coding type based on the service scenario it needs to fulfill.

In other possible implementations, the terminal may send uplink request information to the network device. This uplink request information includes a first channel coding type requested by the terminal based on the current service type or communication environment. The uplink request information may include, but is not limited to, a Buffer Status Report (BSR). Accordingly, the network device can determine the target channel coding type based on the first channel coding type requested by the terminal.

The target channel coding type can take effect upon receiving downlink indication information. Alternatively, the target channel coding type can also take effect during data exchange, such as upon receiving downlink data or when sending uplink data to network devices.

In some possible implementations, the terminal may also report a set of channel coding types it supports to the network device. Specifically, the terminal may send a registration request or a terminal capability response to the network device, which includes a set of channel coding types supported by the terminal. The target channel coding type can be determined from the set of channel coding types.

S304. The terminal encodes or decodes the data exchanged with the network device according to the target channel coding type indicated by the downlink instruction information.

Specifically, when the target channel coding type is in effect on the terminal side, the terminal can encode the uplink data exchanged with the network device according to the target channel coding type, or decode the downlink data received from the network device according to the target channel coding type.

Based on the foregoing description, this application provides a communication method. In this method, the terminal performs data encoding and decoding according to the target channel coding type indicated by the downlink indication information sent by the network device. This enables variable channel coding based on service type, communication environment, or service scenarios required by the network device, providing a more flexible channel coding scheme to meet the channel coding requirements of different communication scenarios. Furthermore, this method supports multiple channel coding types, thereby flexibly meeting the needs of more diverse and demanding communication scenarios.

The communication methods have been explained from the perspectives of network devices and terminals. The following section details the communication methods from an interactive perspective, specifically the methods where the network device actively determines the target channel coding type and the terminal actively requests the first channel coding type.

First, referring to the interaction flowchart of a communication method shown in Figure 4, the method includes the following steps:

S402. The terminal reports the set of channel coding types supported by the terminal in the registration request or terminal capability response.

The terminal capability response, also known as the capability set query response, can include the set of channel coding types supported by the terminal, such as {A, B, C}, in the registration request or capability set query response. Initially, the terminal can use the two existing LDPC BGs in the standard and add a channel coding type field when reporting capabilities.

S404. The network device instructs the terminal to use the target channel coding type based on the current service type, communication environment, or service scenario that the network device needs to meet.

Specifically, network devices can determine the target channel coding type (e.g., A, B, or C) based on the current service type, such as data plane, user plane, control plane, intelligence plane, or security plane, and then instruct the terminal to use that target channel coding type. Similarly, network devices can determine the target channel coding type based on the current communication environment or the service scenario that the network device needs to fulfill, and then instruct the terminal to use that target channel coding type.

It should be noted that network devices can also be classified according to the capabilities of the terminals. For example, the first type of terminal supports channel coding type {A}, the second type of terminal supports channel coding type {A,B}, and the third type of terminal supports channel coding type {A,B,C}.

S406. The terminal selects the corresponding channel coding to encode the uplink data according to the target channel coding type indicated by the network device.

When the terminal receives an instruction from the network device, the target channel coding type takes effect. The terminal then encodes the uplink data according to the effective target channel coding type.

S408: The terminal sends encoded uplink data to the network device.

S410: The network device performs channel decoding on the uplink data sent by the terminal using both pre-indication and post-indication error correction codes in parallel to determine whether the indicated target channel coding type is effective on the terminal side. If so, proceed to S412.

In some examples, network devices can also determine whether the target channel coding type is effective on the terminal side based on feedback from the terminal.

S412. The network device encodes the downlink data according to the target channel coding type.

S414. The network device sends encoded downlink data to the terminal.

The target channel coding type takes effect on the terminal side, and the network device can use the indicated error correction code to decode the channel decoding result. Furthermore, the network device can also transmit downlink data based on the decoding result. In specific implementation, the network device can encode the downlink data using the target channel coding type and then transmit the encoded downlink data.

The specific implementation of network equipment encoding downlink data according to the target channel coding type can be found in the specific implementation of terminal encoding uplink data according to the target channel coding type, and will not be repeated here.

The following examples illustrate this point.

In Example 1, when data services are being performed, switching between traditional LDPCs can be initiated by the network device, as follows:

1. When reporting capabilities, the UE reports the supported data channel coding types {LDPC_A,LDPC_B,LDPC_C};

2. When the UE is performing a service, the network device instructs the UE to use the channel coding type (LDPC_A, LDPC_B, or LDPC_C) based on the specific service type (such as control plane, user plane, data plane, intelligent plane, security plane), or based on perceived changes in the communication environment, or the vertical service scenarios that the network needs to meet.

3. When the UE receives an instruction from the network device, it applies the corresponding channel coding type;

4. The UE selects the corresponding channel code according to the channel coding type indicated by the network device.

After the network side indicates the channel coding type, it can use both pre-indication and post-indication error correction codes in parallel to perform channel decoding on the UE's uplink data, thereby determining whether the indicated channel coding type is effective on the UE side. Alternatively, the network side can use UE feedback to determine whether the channel coding type is effective.

In Example 2, when data services are being conducted, the network device can proactively switch between different channel codes, such as switching from LDPC code to polar code, or from LDPC code to turbo code, as detailed below:

1. When reporting capabilities, the UE reports the supported data channel coding types {LDPC code, POLAR code, TURBO code, convolutional code, RS code...};

2. When the UE is performing a service, the network device instructs the UE to use the channel coding type (LDPC code, POLAR code, TURBO code, convolutional code, RS code, etc.) based on the specific service type, perceived changes in the communication environment, or the vertical service scenarios that the network device needs to meet.

3. When the UE receives an instruction from the network device, it applies the corresponding channel coding type;

4. The UE selects the corresponding channel code according to the channel coding type indicated by the network device.

For the network side's determination of whether the channel coding type is effective, please refer to Example 1, which will not be repeated here.

Example 3: When conducting data services, the network device can proactively switch between traditional LDPC code and AI module codec, as follows:

1. When reporting capabilities, the UE reports the supported data channel coding types {LDPC code, AI module codec};

2. When the UE is performing a service, the network device instructs the UE to use the channel coding type (LDPC code, AI module codec) based on the specific service type, perceived changes in the communication environment, or the vertical service scenarios that the network needs to meet.

3. When the UE receives an instruction from the network device, it applies the corresponding channel coding type;

4. The UE selects the corresponding channel code according to the channel coding type indicated by the network device.

For the network side's determination of whether the channel coding type is effective, please refer to Example 1, which will not be repeated here.

Secondly, referring to the interaction flowchart of another communication method shown in Figure 5, this method includes the following steps:

S502, The terminal sends an uplink request message to the network device.

Specifically, when a terminal performs a service, it can determine the first channel coding type based on the current service type (e.g., data plane, user plane, control plane, intelligence plane) or the current communication scenario (e.g., ground level, elevator, security plane), and send an uplink request message to the network to request the use of the first channel coding type. The uplink request message can be a BSR (Background Request Message), meaning the terminal can request the first channel coding type through a BSR. This uplink request message can be carried in the Physical Uplink Shared Channel (PUSCH) or in other uplink channels.

To facilitate understanding, let's illustrate this with an example of changing communication scenarios. For instance, a signal strength threshold X is set, and the terminal can measure the signal strength Y. If Y < X, it indicates that the current communication environment is poor, and a channel coding with a lower bit error rate and greater resistance to interference can be selected; if Y > X, it is considered that the current communication environment is good, and a channel coding with a higher code rate can be selected.

S504. The network device sends downlink instruction information to the terminal.

Downlink indication information is used to indicate the target channel coding type to be used. The target channel coding type can be the first channel coding type, or other channel coding types, such as the default second channel coding type, or the third channel coding type recommended by the network device. In some examples, the downlink indication information may indicate whether to use the first channel coding type requested by the terminal.

S506. The terminal selects the corresponding channel coding to encode the uplink data according to the target channel coding type indicated by the network device.

Specifically, the network device indicates that a first channel coding type is used, and the terminal selects the first channel coding type to encode the uplink data. The network device indicates that a second channel coding type is not used, for example, it indicates that a second channel coding type or a third channel coding type is used, and the terminal selects the second channel coding type or the third channel coding type to encode the uplink data.

It should be noted that if the terminal sends an uplink request message to request the use of a specific channel coding type (such as the first channel coding type), and does not receive a response from the network device (such as an downlink indication message) within a specified time, it can retransmit the message.

S508: The terminal sends encoded uplink data to the network device.

S510: The network device decodes the uplink data sent by the terminal according to the target channel coding type.

S510: Network devices encode downlink data according to the target channel coding type.

S512, The network device sends encoded downlink data to the terminal.

The following examples illustrate this point.

Example 4: When conducting data services, the UE can actively request switching between traditional LDPC codes, as follows:

1. When a UE is conducting a service, it may send a request to the network device to use a specific channel coding type, depending on the specific service type (e.g., data plane, user plane, control plane, intelligent plane, security plane, etc.) or the communication scenario (e.g., exiting from the basement to the ground or entering an elevator). This request may be sent in the first uplink information (the first uplink information may be carried in the PUSCH or in other uplink channels that may appear in future 6G).

The communication scenario judgment criterion can be as follows: Set a signal strength threshold X, and the UE measures the signal strength Y. If Y < X, the current communication environment is considered poor, and the first channel coding type with a lower bit error rate and better interference resistance is selected, specifically LDPC_A; if Y > X, the current communication environment is considered good, and the second channel coding type with a higher code rate is selected, specifically LDPC_B.

2. The network indicates in the downlink indication information (such as DCI, or other downlink indication information that may appear in 6G) whether to use the first channel coding type requested by the UE;

3. The UE receives downlink indication information from the network device;

4. If the network device indicates that the first channel coding type requested by the UE should be used, then the UE should use the first channel coding; if the network refuses to use the first channel coding type requested by the UE, then the second channel coding should be used.

If the UE does not receive a network response within a specified time after sending a request for a specific channel coding type, it can resend the request.

Example 5: When conducting data services, the UE can actively request to switch between different channel codes, such as switching from LDPC code to POLAR code, or from LDPC code to TURBO code, as detailed below:

1. When a UE performs a service, it sends a request to the network device to use a specific channel coding type, depending on the specific service type (e.g., data plane, user plane, control plane, intelligent plane, security plane, etc.) or the communication scenario (e.g., exiting the basement to the ground or entering an elevator).

Specifically, a signal strength threshold X is set, and the UE measures the signal strength Y. If Y < X, the current communication environment is considered poor, and the first channel coding type with a lower bit error rate and better interference resistance is selected, specifically LDPC_A; if Y > X, the current communication environment is considered good, and the second channel coding type with a higher code rate is selected, specifically POLAR_A.

2. The network provides downlink indication information (such as DCI) to indicate whether to use the specific channel coding type requested by the UE;

3. The UE receives downlink indication information from the network device;

4. If the network device indicates that the first channel coding type requested by the UE should be used, then the UE should use the first channel coding; if the network refuses to use the first channel coding type requested by the UE, then the second channel coding should be used.

If the UE does not receive a network response within a specified time after sending a request for a specific channel coding type, it can resend the request.

Example 6: When performing data services, the UE can actively request to switch between traditional LDPC code and AI module codec, as follows:

1. When a UE performs a service, it sends a request to the network device to use a specific channel coding type, depending on the specific service type (e.g., data plane, user plane, control plane, intelligent plane, security plane, etc.) or the communication scenario (e.g., exiting the basement to the ground or entering an elevator).

Specifically, a signal strength threshold X is set, and the UE measures the signal strength Y. If Y < X, the current communication environment is considered poor, and the first channel coding type with a lower bit error rate and better interference resistance is selected, specifically LDPC_A; if Y > X, the current communication environment is considered good, and the second channel coding type with a higher code rate is selected, specifically AI module encoding and decoding.

2. The network indicates in downlink indication information (such as DCI, or other downlink indication information that may appear in 6G) whether to use the specific channel coding type requested by the UE;

3. The UE receives downlink indication information from the network device;

4. If the network device indicates that the first channel coding type requested by the UE should be used, then the UE should use the first channel coding; if the network refuses to use the first channel coding type requested by the UE, then the second channel coding should be used.

If the UE does not receive a network response within a specified time after sending a request for a specific channel coding type, it can resend the request.

Compared to traditional solutions, the channel coding scheme in this application is more flexible. Furthermore, the channel coding scheme in this application does not affect 5G legacy UEs. When a legacy UE reports its capabilities, it does not report the supported data channel coding types. The network determines that the UE is a legacy UE based on the fact that this field is empty, and uses traditional channel coding to communicate with it.

The scheme proposed in this application is not limited to the POLAR code of the NR standard and the two fixed LDPC codes. It can select different channel coding types based on specific service types (e.g., data plane, user plane, control plane, intelligence plane, security plane), changes in the perceived communication environment, or vertical service scenarios that the network needs to meet. For example, a UE can select a suitable channel coding scheme by initiating a request based on the service type, changes in the perceived communication environment, or vertical service scenarios. Alternatively, the network device can proactively select a suitable channel coding method based on the service type, communication environment, or vertical service scenarios that the network device needs to meet, thereby achieving flexible and variable channel coding. Furthermore, different UEs can be classified according to their capabilities. UEs report their capabilities, including a set of channel coding types they support. The network device determines a suitable channel coding scheme from the set of channel coding types based on the service type, changes in the perceived communication environment, or vertical industry scenarios, and instructs the UE to use the appropriate channel coding scheme, thus achieving variable channel coding.

Based on the aforementioned communication method, this application also provides a communication device. Figure 6 is an example of the composition of a communication device provided in an embodiment of this application. The communication device can be a terminal, including but not limited to mobile phones, smart wearable devices (such as smartwatches), and other electronic devices. Taking a mobile phone as an example, the communication device may include a processor 610, an external memory interface 620, an internal memory 621, a display screen 630, a camera 640, antenna 1, antenna 2, a mobile communication module 650, and a wireless communication module 660, etc.

It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the communication device. In other embodiments, the communication device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The processor 610 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and/or a neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors.

It is understood that the interface connection relationships between the modules illustrated in this embodiment are merely illustrative and do not constitute a limitation on the structure of the electronic device. In other embodiments of this application, the electronic device may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

The external storage interface 620 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device. The external memory card communicates with the processor 610 through the external storage interface 620 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

Internal memory 621 can be used to store executable program code, including instructions. Processor 610 executes various functional applications and data processing of the electronic device by running the instructions stored in internal memory 621. Internal memory 621 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of the electronic device (such as audio data, phonebook, etc.). Furthermore, internal memory 621 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 610 executes various functional applications and data processing of the electronic device by running instructions stored in internal memory 621 and/or instructions stored in memory located within the processor.

The wireless communication function of electronic devices can be implemented through antenna 1, antenna 2, mobile communication module 650, wireless communication module 660, modem processor, and baseband processor.

Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

The mobile communication module 650 can provide solutions for wireless communication applications including 2G/6G/4G/5G/6G in electronic devices. The mobile communication module 650 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 650 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 650 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 650 may be housed in processor 610. In some embodiments, at least some functional modules of the mobile communication module 650 and at least some modules of the processor 610 may be housed in the same device.

In some embodiments, the electronic device initiates or receives call requests via the mobile communication module 650 and the antenna 1.

In addition, an operating system runs on top of the aforementioned components. Examples include iOS, Android, and Windows. Applications can be installed and run on this operating system.

Figure 7 illustrates another example of the composition of a communication device provided in an embodiment of this application. This communication device can be a network device, such as a base station. Figure 7 shows a simplified schematic diagram of a base station structure. The base station includes sections 710, 720, and 730. Section 710 is mainly used for baseband processing and controlling the base station; section 710 is typically the control center of the base station, often referred to as a processor, used to control the base station to perform the processing operations on the network device side in the above method embodiments. Section 720 is mainly used for storing computer program code and data. Section 730 is mainly used for transmitting and receiving radio frequency signals and converting radio frequency signals to baseband signals; section 730 is often referred to as a transceiver module, transceiver, transceiver circuit, or transceiver unit. The transceiver module of section 730, also referred to as a transceiver or transceiver unit, includes an antenna 733 and a radio frequency circuit (not shown in the figure), wherein the radio frequency circuit is mainly used for radio frequency processing. Optionally, the device used to implement the receiving function in part 730 can be regarded as a receiver, and the device used to implement the transmitting function can be regarded as a transmitter. That is, part 730 includes receiver 732 and transmitter 731. The receiver can also be called a receiving module, receiver, or receiving circuit, etc., and the transmitter can be called a transmitting module, transmitter, or transmitting circuit, etc.

Sections 710 and 720 may include one or more circuit boards, each of which may include one or more processors and one or more memories. The processors are used to read and execute programs from the memories to implement baseband processing functions and control the base station. If multiple circuit boards exist, they can be interconnected to enhance processing capabilities. As an alternative implementation, multiple circuit boards may share one or more processors, multiple circuit boards may share one or more memories, or multiple circuit boards may simultaneously share one or more processors.

For example, in one implementation, the transceiver module of section 730 is used to execute the transceiver-related processes performed by the base station in the embodiment shown in FIG4. The processor of section 710 is used to execute the processing-related processes performed by the base station in the embodiment shown in FIG4.

It should be understood that Figure 7 is merely an example and not a limitation, and the network devices described above, including processors, memory, and transceivers, may not depend on the structure shown in Figure 7.

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

In this application, the terminal or network device may include a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on top of the operating system layer. The hardware layer may include hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory (also known as main memory). The operating system layer may be any one or more computer operating systems that implement business processing through processes, such as Linux, Unix, Android, iOS, or Windows. The application layer may include applications such as browsers, address books, word processing software, and instant messaging software.

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

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 modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules 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 indirect coupling or communication connection through some interfaces, apparatuses, or modules, and may be electrical, mechanical, or other forms.

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

Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

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

The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims (17)

A communication method, characterized in that the method includes: The target channel coding type is determined based on the current service type, communication environment, or service scenario that the network device needs to meet, or based on the first channel coding type requested by the terminal based on the current service type or communication environment. Send downlink indication information to the terminal, the downlink indication information instructing the terminal to use the target channel coding type. According to the method of claim 1, the step of determining the target channel coding type allocated to the terminal includes: Obtain the current service type, communication environment, or service scenario that the network equipment needs to meet; The target channel coding type assigned to the terminal is determined based on the mapping relationship between the service type, the communication environment, or the service scenario and the channel coding type. The method according to claim 2, characterized in that the method further comprises: Receive data sent by the terminal; The data is decoded using a first error correction code and a second error correction code. Based on the decoding result, it is determined whether the target channel coding type is effective on the terminal side. The first error correction code is the error correction code before sending the downlink indication information, and the second error correction code is the error correction code after sending the downlink indication information. The method according to claim 2, characterized in that the method further comprises: The system receives feedback information from the terminal, which indicates whether the target channel coding type is effective on the terminal side. According to the method of claim 1, the step of determining the target channel coding type allocated to the terminal includes: The receiving terminal sends uplink request information, which includes the first channel coding type requested by the terminal based on the current service type or communication environment; Based on the first channel coding type, the target channel coding type assigned to the terminal is determined. The method according to claim 4, wherein determining the target channel coding type allocated to the terminal based on the first channel coding type includes: When there are sufficient resources corresponding to the first channel coding type, the first channel coding type is determined as the target channel coding type; or, When the resources corresponding to the first channel coding type are insufficient, the default second channel coding type or the third channel coding type recommended by the terminal is determined as the target channel coding type. The method according to any one of claims 1 to 6, characterized in that the method further comprises: Obtain the set of channel coding types supported by the terminal, and determine the target channel coding type from the set of channel coding types. According to the method of claim 7, the step of obtaining the set of channel coding types supported by the terminal includes: The terminal receives a registration request or a terminal capability response, wherein the registration request or the terminal capability response includes a set of channel coding types supported by the terminal. The method according to any one of claims 1 to 8 is characterized in that the channel coding type includes any one or more of low-density parity-check (LDPC) codes, POLAR codes, TURBO codes, convolutional codes or Reed-Solomon codes, and AI module encoding/decoding. A communication method, characterized in that the method includes: The terminal receives downlink indication information sent by a network device. The downlink indication information indicates the target channel coding type used by the terminal. The target channel coding type is determined based on the current service type, communication environment, or service scenario that the network device needs to meet, or it is determined based on the first channel coding type requested by the terminal based on the current service type or communication environment. The data interacting with the network device is encoded or decoded according to the target channel coding type indicated by the downlink indication information. The method according to claim 10, characterized in that the method further comprises: Report the current service type or communication environment to the network device; or, The terminal sends an uplink request to the network device, the uplink request including the first channel coding type requested by the terminal based on the current service type or communication environment. The method according to claim 10 or 11 is characterized in that the target channel coding type takes effect upon receiving the downlink indication information. The method according to any one of claims 10 to 12, characterized in that the method further comprises: The network device reports a set of channel coding types supported by the terminal, and the target channel coding type is determined from the set of channel coding types. The method according to any one of claims 1 to 13, characterized in that, reporting the set of channel coding types supported by the terminal to the network device includes: Send a registration request or terminal capability response to the network device, wherein the registration request or terminal capability response includes a set of channel coding types supported by the terminal. The method according to any one of claims 1 to 8 is characterized in that the channel coding type includes any one or more of low-density parity-check (LDPC) codes, POLAR codes, TURBO codes, convolutional codes or Reed-Solomon codes, and AI module encoding/decoding. A communication device, characterized in that the communication device comprises: Memory, used to store computer instructions; A processor for executing a computer program or computer instructions stored in the memory, causing the communication device to perform the method as described in any one of claims 1 to 15. A computer storage medium for storing a computer program, which, when executed, implements the communication method according to any one of claims 1 to 15.