Communication method

Abstract

The invention provides a communication method and device, which are used for realizing source-channel joint coding in a wireless communication system. The method comprises: a terminal device sends an entropy estimation value of service data to an access network device, and receives scheduling information from the access network device, the entropy estimation value being used for representing distribution of a bit sequence of the service data in the service data, the scheduling information being used for configuring resources for transmitting the service data, and the scheduling information being related to the entropy estimation value. In this way, source-channel joint coding can be realized under the architecture of source-channel coding separation, and the access network equipment considers the entropy estimation value during data scheduling, so that the performance can be greatly improved.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a communication method and device. Background Art

[0002] In recent years, with the demand for improved communication efficiency in the 5G and 6G eras, and the implementation of artificial intelligence technology in various fields, semantic communication technology based on deep learning has become a feasible way to solve the bottleneck of traditional information transmission. Compared with the traditional communication technology that encodes the source and transmits it, semantic communication technology encodes the semantic information extracted from the source and transmits it. Existing research shows that semantic communication has higher communication efficiency and anti-channel interference capabilities. The semantic communication system is an end-to-end system composed of modules such as semantic coding, source-channel joint coding, source-channel joint decoding, and semantic decoding. It is used for semantic communication of multimodal information such as images / videos, text, and voice. Among them, variable rate transmission of semantic communication can be achieved through source-channel joint coding, thereby achieving a significant performance improvement.

[0003] In current wireless communication systems, the application layer of terminal devices or core network devices is responsible for source coding, while the network devices are responsible for channel coding. How to apply source-channel joint coding in wireless communication systems needs to be solved urgently. Summary of the invention

[0004] The present application provides a communication method and apparatus for implementing source-channel joint coding in a wireless communication system.

[0005] In a first aspect, a communication method is provided, wherein the executor of the method may be a terminal device or a chip, a chip system or a circuit located in the terminal device, and the method may be implemented by the following steps: sending an entropy estimate of service data to an access network device, and receiving scheduling information from the access network device, wherein the entropy estimate is used to characterize the distribution of a bit sequence of the service data in the service data, the scheduling information is used to configure resources for transmitting the service data, and the scheduling information is related to the entropy estimate.

[0006] In the embodiment of the present application, the entropy estimation value for source coding is sent to the access network device through the terminal device, so that the access network device can perform scheduling according to the entropy estimation value. In this way, source-channel joint coding can be implemented under the architecture of source-channel coding separation, and the access network device considers the entropy estimation value when performing data scheduling, which can achieve a significant performance improvement.

[0007] In a possible design, before sending the entropy estimation value of the service data, a scheduling request may be sent, and the scheduling request indicates a semantic fault-tolerant service associated with the service data. Through the above design, the access network device can be requested to allocate resources dedicated to the semantic fault-tolerant service, thereby avoiding using the same resources to transmit data for both the semantic fault-tolerant service and the non-semantic fault-tolerant service.

[0008] In a possible design, the method further includes: sending a buffer status report, where the buffer status report indicates a semantic fault-tolerant service associated with the service data. Through the above design, the terminal device and the network device can align the services associated with the service data, which is beneficial to improving communication performance.

[0009] In a possible design, the entropy estimation value is carried in the buffer status report.

[0010] In a possible design, the scheduling information indicates that the configured resources are for the semantic fault-tolerant service. Through the above design, the terminal device and the network device can align the resources for transmitting the service data, which is beneficial to improving communication performance.

[0011] In a possible design, the method further includes: sending service data according to the logical channel priority associated with the semantic fault-tolerant service. In this way, it is possible to avoid filling the data of the semantic fault-tolerant service and the data of the non-semantic fault-tolerant service into the same data block.

[0012] In a possible design, the method further includes: receiving a first message, where the first message is used to configure the data radio bearer and the logical channel group for the semantic fault-tolerant service, and the service data is associated with the semantic fault-tolerant service. By configuring a separate data radio bearer and logical channel group for the semantic fault-tolerant service in the above manner, it is possible to avoid sending the semantic fault-tolerant service and the non-semantic fault-tolerant service in the same data radio bearer and logical channel group.

[0013] In a possible design, the method further includes: receiving configuration information, where the configuration information is used to enable the reporting of the entropy estimation value. Through the above design, the terminal device can be flexibly controlled to report the entropy estimation value.

[0014] In a second aspect, a communication method is provided. The execution entity of this method can be an access network device or a chip, chip system, or circuit located in the access network device. This method can be implemented through the following steps: receiving an entropy estimation value from a terminal device, where the entropy estimation value is used to characterize the distribution of the bit sequence of the service data in the service data; sending scheduling information to the terminal device, where the scheduling information is used to configure the resources for transmitting the service data, and the scheduling information is determined according to the entropy estimation value.

[0015] In the embodiments of the present application, the entropy estimation value for source coding is sent to the access network device by the terminal device, so that the access network device can perform scheduling according to the entropy estimation value. In this way, source-channel joint coding can be achieved under the architecture of separated source-channel coding. Moreover, when the access network device performs data scheduling, considering the entropy estimation value can obtain a significant performance improvement.

[0016] In a possible design, before receiving the entropy estimation value of the service data, a scheduling request can be received, and the scheduling request indicates that the service data is associated with a semantic fault-tolerant service. Through the above design, the access network device can be requested to allocate resources dedicated to the semantic fault-tolerant service, thereby avoiding using the same resources to transmit data for both the semantic fault-tolerant service and the non-semantic fault-tolerant service.

[0017] In a possible design, the method further includes: receiving a buffer status report, and the buffer status report indicates that the service data is associated with a semantic fault-tolerant service. Through the above design, the terminal device and the network device can align the services associated with the service data, which is beneficial to improving communication performance.

[0018] In a possible design, the entropy estimation value is carried in the buffer status report.

[0019] In a possible design, the scheduling information indicates that the configured resources are for the semantic fault-tolerant service.

[0020] In a possible design, before sending the entropy estimation value of the service data, a first message can be sent, and the first message is used to configure the data radio bearer and the logical channel group for the semantic fault-tolerant service.

[0021] In a possible design, the method further includes: sending configuration information, and the configuration information is used to enable reporting of the entropy estimation value.

[0022] In a third aspect, a communication method is provided. The execution subject of this method can be an access network device or a chip, a chip system, or a circuit located in the access network device. This method can be implemented through the following steps: receiving information about the entropy estimation value from the core network device, where the entropy estimation value is used to characterize the distribution of the bit sequence of the service data in the service data; sending scheduling information to the terminal device, where the scheduling information is used to configure resources for transmitting the service data, and the scheduling information is determined according to the entropy estimation value.

[0023] In the embodiments of the present application, the entropy estimation value for source coding is sent to the access network device by the core network device, so that the access network device can perform scheduling according to the entropy estimation value. In this way, source-channel joint coding can be achieved under the architecture of separated source-channel coding. Moreover, when the access network device performs data scheduling, considering the entropy estimation value can obtain a significant performance improvement.

[0024] In a possible design, the information of the entropy estimation value is the entropy estimation value. Through the above design, the access network device can save computing resources and reduce the energy consumption of the access network device by directly indicating the entropy estimation value.

[0025] In a possible design, the information of the entropy estimation value includes an entropy estimation value model and service data. Through the above design, in subsequent downlink transmission scheduling, the core network device does not need to send the entropy estimation value model, thereby saving signaling overhead between the access network device and the core network device.

[0026] In a possible design, the scheduling information indicates that the configured resources are for semantic fault tolerance services. Through the above design, the terminal device and the network device can align the resources for transmitting service data, which is beneficial to improving communication performance.

[0027] In a possible design, the method further includes: sending a first message, where the first message is used to configure a data radio bearer and a logical channel group for the semantic fault tolerance service, and the service data is associated with the semantic fault tolerance service. By configuring a separate data radio bearer and logical channel group for the semantic fault tolerance service in the above manner, it is possible to avoid sending semantic fault tolerance services and non-semantic fault tolerance services in the same data radio bearer and logical channel group.

[0028] In a fourth aspect, a communication method is provided. The execution entity of this method can be a core network device or a chip, chip system, or circuit located in the core network device. This method can be implemented through the following steps: determining the information of the entropy estimation value, where the entropy estimation value is used to characterize the distribution of the bit sequence of the service data in the service data; sending the information.

[0029] In the embodiments of the present application, the core network device sends the entropy estimation value for source coding to the access network device, so that the access network device can perform scheduling according to the entropy estimation value. Through this method, source-channel joint coding can be achieved in an architecture where source-channel coding is separated, and moreover, when the access network device performs data scheduling, considering the entropy estimation value can obtain a significant performance improvement.

[0030] In a possible design, the information is the entropy estimation value. Through the above design, the access network device can save computing resources and reduce the energy consumption of the access network device by directly indicating the entropy estimation value.

[0031] In a possible design, the information includes an entropy estimation value model and service data. Through the above design, in subsequent downlink transmission scheduling, the core network device does not need to send the entropy estimation value model, thereby saving signaling overhead between the access network device and the core network device.

[0032] In a fifth aspect, the present application further provides a communication device, which is a terminal device or a chip in a terminal device. The communication device has the function of implementing any of the methods provided in the first aspect above. The communication device can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more units or modules corresponding to the above functions.

[0033] In a possible design, the communication device includes: a processor configured to support the communication device in executing the corresponding functions of the terminal device in the above-described method. The communication device may further include a memory, which can be coupled to the processor and stores the necessary program instructions and data of the communication device. Optionally, the communication device further includes an interface circuit for supporting communication between the communication device and devices such as service satellites, for example, the transceiver of data or signals. Exemplarily, the communication interface can be a transceiver, a circuit, a bus, a module, or other types of communication interfaces.

[0034] In a possible design, the communication device includes corresponding functional modules respectively for implementing the steps in the above method. The functions can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

[0035] In a possible design, the structure of the communication device includes a processing unit and a communication unit, and these units can execute the corresponding functions in the above method examples. For specific details, refer to the description in the method provided in the first aspect, and details are not elaborated here.

[0036] In a sixth aspect, the present application further provides a communication device, which is an access network device or a chip in an access network device. The communication device has the function of implementing any of the methods provided in the second aspect or the third aspect above. The communication device can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more units or modules corresponding to the above functions.

[0037] In a possible design, the communication device includes: a processor configured to support the communication device in executing the corresponding functions of the access network device in the above-described method. The communication device may further include a memory, which can be coupled to the processor and stores the necessary program instructions and data of the communication device. Optionally, the communication device further includes an interface circuit for supporting communication between the communication device and devices such as terminal devices and core network devices, for example, the transceiver of data or signals. Exemplarily, the communication interface can be a transceiver, a circuit, a bus, a module, or other types of communication interfaces.

[0038] In a possible design, the communication device includes corresponding functional modules, which are respectively used to implement the steps in the above method. The functions can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

[0039] In a possible design, the structure of the communication device includes a processing unit and a communication unit, and these units can execute the corresponding functions in the above method examples. For specific details, refer to the descriptions in the methods provided in the second aspect or the third aspect, and details are not elaborated here.

[0040] In the seventh aspect, the present application further provides a communication device, and the device is a core network device or a chip in a core network device. The communication device has the function of implementing any of the methods provided in the fourth aspect above. The communication device can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more units or modules corresponding to the above functions.

[0041] In a possible design, the communication device includes: a processor, which is configured to support the communication device to execute the corresponding functions of the core network device in the above method. The communication device may further include a memory, and the memory can be coupled to the processor and stores the necessary program instructions and data of the communication device. Optionally, the communication device further includes an interface circuit, and the interface circuit is used to support the communication between the communication device and other devices such as access network devices, for example, the transceiver of data or signals. Exemplarily, the communication interface can be a transceiver, a circuit, a bus, a module or other types of communication interfaces.

[0042] In a possible design, the communication device includes corresponding functional modules, which are respectively used to implement the steps in the above method. The functions can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

[0043] In a possible design, the structure of the communication device includes a processing unit and a communication unit, and these units can execute the corresponding functions in the above method examples. For specific details, refer to the descriptions in the methods provided in the fourth aspect, and details are not elaborated here.

[0044] In the eighth aspect, a communication device is provided, including a processor and an interface circuit. The interface circuit is used to receive signals from other communication devices outside the communication device and transmit them to the processor, or send signals from the processor to other communication devices outside the communication device. The processor is used to implement the methods in the first aspect and any possible design through logic circuits or executing code instructions.

[0045] In a ninth aspect, a communication device is provided, which includes a processor and an interface circuit. The interface circuit is configured to receive signals from other communication devices outside the communication device and transmit them to the processor, or send signals from the processor to other communication devices outside the communication device. The processor is configured to implement the methods in the foregoing second aspect or third aspect and any possible designs through logic circuits or by executing code instructions.

[0046] In a tenth aspect, a communication device is provided, which includes a processor and an interface circuit. The interface circuit is configured to receive signals from other communication devices outside the communication device and transmit them to the processor, or send signals from the processor to other communication devices outside the communication device. The processor is configured to implement the methods in the foregoing fourth aspect and any possible designs through logic circuits or by executing code instructions.

[0047] In an eleventh aspect, a computer-readable storage medium is provided, in which computer programs or instructions are stored. When the computer programs or instructions are executed by a processor, the methods in any one of the foregoing first aspect to fourth aspect and any possible designs are implemented.

[0048] In a twelfth aspect, a computer program product storing instructions is provided. When the instructions are run by a processor, the methods in the foregoing first aspect to fourth aspect and any possible designs are implemented.

[0049] In a thirteenth aspect, a chip system is provided. The chip system includes a processor and may further include a memory, and is configured to implement the methods in the foregoing first aspect to fourth aspect and any possible designs. The chip system may be composed of chips, or may include chips and other discrete devices.

[0050] In a fourteenth aspect, a communication system is provided. The system includes the device described in the first aspect (such as a terminal device) and the device described in the second aspect (such as an access network device).

[0051] In a fifteenth aspect, a communication system is provided. The system includes the device described in the third aspect (such as an access network device) and the device described in the fourth aspect (such as a core network device). Optionally, a terminal device may also be included.

[0052] The technical effects that can be achieved by the technical solutions in any one of the foregoing fifth aspect to fifteenth aspect may be described with reference to the technical effects that can be achieved by the technical solutions in the foregoing first aspect to fourth aspect. Repeated parts will not be elaborated. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 It is a schematic diagram of the architecture of a communication system according to an embodiment of the present application;

[0054] Figure 2A It is a schematic diagram of a protocol layer structure according to an embodiment of the present application;

[0055] Figure 2B It is a schematic diagram of a data packet structure according to an embodiment of the present application;

[0056] Figure 3A It is a schematic diagram of downlink data transmission according to an embodiment of the present application;

[0057] Figure 3B It is a schematic diagram of a data packet encapsulation structure according to an embodiment of the present application;

[0058] Figure 4 It is a schematic diagram of the process of a communication method according to an embodiment of the present application;

[0059] Figure 5 It is a schematic diagram of an uplink scheduler according to an embodiment of the present application;

[0060] Figure 6 It is a schematic diagram of the process of a communication method according to an embodiment of the present application;

[0061] Figure 7 It is a schematic diagram of a downlink scheduler according to an embodiment of the present application;

[0062] Figure 8 It is a schematic diagram of the structure of a communication device according to an embodiment of the present application;

[0063] Figure 9 It is a schematic diagram of the structure of a communication device according to an embodiment of the present application. Detailed implementation manners

[0064] Hereinafter, some terms in the embodiments of the present application will be explained to facilitate the understanding of those skilled in the art.

[0065] 1. Semantic communication: Different from traditional communication, the main task of traditional communication is to achieve accurate transmission of information at the bit level or symbol level. Therefore, the bit error rate (BER) or symbol error rate (SER) is used as its main performance indicator. In contrast, semantic communication focuses on how the transmitted symbols accurately convey the required meaning. Some current video applications add forward error correction (FEC) at the application layer to have fault tolerance. Fault tolerance can be understood as follows: The sender encodes the original information vector A into a potential representation vector B within a specified semantic feature domain and transmits it over the air interface. The potential representation vector received by the receiver is B'. Although B ≠ B', within the above-mentioned semantic feature domain, the Hamming distance between the potential representation vector B' received by the receiver and the potential representation vector B sent by the sender does not exceed a specified threshold ε. The receiver can decode the received potential representation vector B' into A', and A' = A. In this case, the above-mentioned fault tolerance can be quantified as ε.

[0066] 2. Semantic fault-tolerant service: It can also be called a fault-tolerant service. A semantic fault-tolerant service can refer to a service in which the source or application layer decoding has fault tolerance, that is, the source or application layer can correctly recover the content based on the incorrect data.

[0067] Alternatively, a semantic fault-tolerant service can also be a service that adds forward error correction (FEC) at the application layer. Due to the existence of FEC, even if the received data has transmission errors, in some scenarios, such as when the number of incorrect bits transmitted is small and still within the error correction range, the application layer can use FEC to correct the incorrect data and recover the correct content.

[0068] Alternatively, a semantic fault-tolerant service can also be a service that uses artificial intelligence (AI) decoding. From the perspective of information theory, since the AI decoding model can provide additional information entropy, although the transmitted incorrect data has lost some information entropy, with the help of AI decoding, the lost information entropy can still be supplemented, enabling the information content to be correctly recovered.

[0069] It should be noted that the "semantic fault-tolerant service" is only an exemplary name, and this application does not limit the naming of this type of service. In specific implementations, as long as a service can correctly decode based on incorrect data packets, it can be understood as the semantic fault-tolerant service described in this application.

[0070] 3. Entropy Estimation Value: It can also be referred to as entropy value, information entropy, etc. In information theory, the entropy estimation value reflects the uncertainty of information. The larger the entropy estimation value of business data, the richer the amount of information. Conversely, the smaller the entropy estimation value, the scarcer the amount of information.

[0071] Next, the technical solutions in the embodiments of the present application will be described with reference to the accompanying drawings in the embodiments of the present application.

[0072] The technical solutions in the embodiments of the present application can be applied to various communication systems, such as Universal Mobile Telecommunications System (UMTS), Wireless Local Area Network (WLAN), Wireless Fidelity (Wi-Fi) system, 4th Generation (4G) mobile communication system, such as Long Term Evolution (LTE) system, 5th Generation (5G) mobile communication system, such as New Radio (NR) system, and future evolved communication systems, such as 6th Generation (6G) mobile communication system, etc.

[0073] In particular, the embodiments of the present application are applicable to semantic communication systems.

[0074] The present application will present various aspects, embodiments or features around a system that may include multiple devices, components, modules, etc. It should be understood and appreciated that each system may include additional devices, components, modules, etc., and / or may not include all the devices, components, modules, etc. discussed in conjunction with the accompanying drawings. In addition, combinations of these solutions can also be used. Additionally, in the embodiments of the present application, words such as "exemplarily", "for example" are used to represent examples, illustrations or explanations. Any embodiment or design solution described as an "example" in the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of the word "example" is intended to present concepts in a specific manner. In the embodiments of the present application, "(of)", "corresponding", and "corresponding" may sometimes be used interchangeably. It should be noted that when not emphasizing their differences, the meanings they convey are the same.

[0075] To facilitate the understanding of the embodiments of the present application, first, Figure 1 the communication system shown in Figure 1As shown in the figure, the communication system 1000 includes a radio access network (RAN) 100 and a core network (CN) 200. Optionally, the communication system 1000 may further include a data network (DN) 300.

[0076] The RAN 100, CN 100, and DN 300 involved in the following will be described in detail respectively. Figure 1 The RAN 100, CN 100, and DN 300 involved in the following will be described in detail respectively.

[0077] (1) RAN 100

[0078] The RAN 100 may include at least one radio access network device (also referred to as an access network device, such as 110a and 110b in Figure 1 ), and may further include at least one terminal device (such as 120a - 120j in Figure 1 ). The terminal device may be connected to the radio access network device wirelessly. The terminal devices and the access network devices may be connected to each other by wire or wirelessly.

[0079] The access network device and the terminal device may be in a fixed position or movable. The access network device and the terminal device may be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; may also be deployed on water; may also be deployed on airplanes, balloons, and artificial satellites in the air. The embodiments of the present application do not limit the application scenarios of the access network device and the terminal device. In addition, the roles of the access network device and the terminal device may be relative. For example, Figure 1 the helicopter or drone 120i in Figure 1 may be configured as a mobile access network device. For the terminal devices 120j that access the radio access network 100 through 120i, 120i is an access network device; but for the first access network device 10a, 120i is a terminal device, that is, the communication between 110a and 120i is through a radio air interface protocol. Of course, the communication between 110a and 120i may also be through an interface protocol between access network devices. At this time, relative to 110a, 120i is also an access network device. Therefore, the access network device and the terminal device can both be uniformly referred to as communication devices. Figure 1 The 110a and 110b in

[0080] (1.1) Terminal device

[0081] The terminal device can also be referred to as user equipment (UE), terminal, user device, access terminal, user unit, user station, mobile station (MS), remote station, remote terminal, mobile device, user terminal, terminal unit, terminal station, terminal device, wireless communication device, user agent, or user device.

[0082] For example, the terminal device in the embodiments of the present application can be a mobile phone, personal digital assistant (PDA) computer, laptop computer, tablet (Pad), drone, computer with wireless transceiver function, machine type communication (MTC) terminal device, virtual reality (VR) terminal device, augmented reality (AR) terminal device, internet of things (IoT) terminal device, wireless terminal device in industrial control, wireless terminal device in self-driving, wireless terminal device in remote medical, wireless terminal device in smart grid, wireless terminal device in transportation safety, wireless terminal device in smart city, wireless terminal device in smart home (such as game consoles, smart TVs, smart speakers, smart refrigerators, and fitness equipment, etc.), in-vehicle terminal device.

[0083] (1.2) Access network device

[0084] The access network device can be a base station, evolved NodeB (eNodeB), access point (AP), transmission reception point (TRP), next generation NodeB (gNB), next generation base station in a 6G mobile communication system, base station in a future mobile communication system, or access node in a WiFi system, etc. The access network device can be a macro base station, micro base station or indoor station, relay node or donor node, or a radio controller in an open RAN (O-RAN or ORAN) or cloud radio access network (CRAN) scenario. Optionally, the access network device can also be a server, wearable device, vehicle or in-vehicle device, etc. For example, the access network device in vehicle to everything (V2X) technology can be a road side unit (RSU). All or part of the functions of the access network device in this application can also be implemented by software functions running on hardware, or by virtualized functions instantiated on a platform (such as a cloud platform). The access network device 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 network device.

[0085] In another possible scenario, multiple access network devices cooperate to assist the terminal device in achieving wireless access, and different access network devices respectively implement part of the functions of the base station. For example, the access network device can be a central unit (CU), distributed unit (DU), CU-control plane (CP), CU-user plane (UP), or radio unit (RU), etc. The CU and DU can be set separately, or can also be included in the same network element, such as a baseband unit (BBU). The RU can be included in a radio frequency device or radio frequency unit, such as included in a remote radio unit (RRU), active antenna unit (AAU) or remote radio head (RRH).

[0086] In different systems, the CU (or CU-CP and CU-UP), DU, or RU may also have different names, but those skilled in the art can understand their meanings. For example, in the ORAN system, the CU may also be referred to as O-CU (Open CU), the DU may also be referred to as O-DU, the CU-CP may also be referred to as O-CU-CP, the CU-UP may also be referred to as O-CU-UP, and the RU may also be referred to as O-RU. For the sake of description convenience, in this application, the CU, CU-CP, CU-UP, DU, and RU are used as examples for description. Any one of the CU (or CU-CP, CU-UP), DU, and RU in this application may be implemented by a software module, a hardware module, or a combination of a software module and a hardware module.

[0087] In the embodiments of this application, the functions of the access network device may also be executed by a module (such as a chip) in the access network device, or may be executed by a control subsystem including the functions of the access network device. Here, the control subsystem including the functions of the access network device may be a control center in the above application scenarios such as smart grid, industrial control, intelligent transportation, and smart city. The functions of the terminal device may also be executed by a module (such as a chip or a modem) in the terminal device, or may be executed by a device including the functions of the terminal.

[0088] (2) CN

[0089] CN200 may include multiple core network elements, and the radio access network device may be connected to the core network elements by wireless or wired means. The core network elements and the radio access network device may be independent different physical devices, or the functions of the core network elements and the logical functions of the radio access network device may be integrated on the same physical device, or the functions of some core network elements and some functions of the radio access network device may be integrated on a physical device.

[0090] Taking the 5G communication system as an example, the core network elements in CN200 may include an access and mobility management function (AMF) network element, a session management function (SMF) network element, a user plane function (UPF) network element, a policy control function (PCF) network element, an application function (AF) network element, etc. For the specific descriptions of the above core network elements, reference may be made to the relevant technical specifications of 3GPP.

[0091] (3) DN300

[0092] DN300, which can also be referred to as a packet data network (PDN), is a network outside the operator's network. Multiple application servers corresponding to various services can be deployed in DN300 to provide various possible services for terminal devices.

[0093] It can be understood that the solutions in the embodiments of this application can be applicable to various possible communication systems, such as 5G communication systems or future 6G communication systems. The above network elements or functions can be either network elements in hardware devices, software functions running on dedicated hardware, or virtualized functions instantiated on a platform (e.g., a cloud platform). In addition, Figure 1 This is just a schematic diagram, and other access network devices can also be included in the RAN of this communication system, such as wireless relay devices and wireless backhaul devices.

[0094] In Figure 1 In the network architecture shown, a user plane data transmission channel can be established for the terminal device through a control plane signaling interaction process (such as a protocol data unit (PDU) session establishment process). Then, the terminal device can transmit data with the application server deployed in the DN through the user plane data transmission channel. For example, the application server can send a downlink data packet to the terminal device, and the transmission path of the downlink data packet is: application server → UPF network element → access network device → terminal device; correspondingly, the terminal device can send an uplink data packet to the application server, and the transmission path of the uplink data packet is: terminal device → access network device → UPF network element → application server.

[0095] Figure 2A This is a schematic diagram of the protocol layer structure. Refer to Figure 2A As shown, the terminal device and the access network device can follow the access network protocol layer structure, and the description of the access layer protocol layer structure is referred to below. The protocol layer structure between the access network device and the UPF network element can include the L1 layer (i.e., the physical layer), the L2 layer (i.e., the data link layer), the user datagram protocol (UDP) layer, the internet protocol (IP) layer, the general packet radio service (GPRS) tunnel protocol (GTP)-user plane (GTP-U) layer, etc.; in addition, the UPF network element can also include a PDU session layer that is peer to the PDU session layer of the terminal device. The protocol layer structure between the UPF network element and the application server can include the L1 layer and the L2 layer, and also includes other layers, specifically referring to existing protocols; in addition, the application server can also include an application layer that is peer to the application layer of the terminal device.

[0096] Among them, the access network device can receive GTP-U data packets from the UPF network element through the NG interface (which can also be referred to as the N3 interface or the NG-U tunnel). For example, refer to Figure 2B As shown, the GTP-U data packet includes a GTP-U header, an inner IP (inner IP) header, a TCP header, and data. The GTP-U header includes an outer IP (outer IP) header, a UDP header, and a GTP header.

[0097] Next, the protocol layer structure between the access network device and the terminal device will be introduced.

[0098] The access network protocol layer structure between the access network device and the terminal device can include a control plane protocol layer structure and a user plane protocol layer structure. The above Figure 2A uses the user plane protocol structure as an example for illustration. For example, the control plane protocol layer structure can include a radio resource control (RRC) layer, a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, a media access control (MAC) layer, and a physical layer (PHY); the user plane protocol layer structure can include a PDCP layer, an RLC layer, a MAC layer, and a physical layer. In a possible implementation, a service data adaptation protocol (SDAP) layer can also be included above the PDCP layer. Among them, the SDAP layer, PDCP layer, RLC layer, MAC layer, and physical layer can also be collectively referred to as the access layer. According to Figure 2A it can be seen that the terminal device also includes a non-access layer, such as a PDU session layer, an application layer, etc. For specific descriptions of the above various protocol layers, reference can be made to the relevant technical specifications of the 3rd generation partnership project (3GPP).

[0099] When the access network device and the terminal device perform user plane data transmission, the data needs to pass through the user plane protocol layers, such as the SDAP layer, the PDCP layer, the RLC layer, the MAC layer, and the physical layer. Exemplarily, data is transmitted between the access network device and the terminal device by establishing at least one data radio bearer (DRB), and each DRB can correspond to a set of functional entity sets. For example, the set of functional entities can include a PDCP layer entity, at least one RLC layer entity corresponding to the PDCP layer entity, at least one MAC layer entity corresponding to at least one RLC layer entity, and at least one physical layer entity corresponding to at least one MAC layer entity.

[0100] Taking the downlink data transmission as an example, Figure 3A it shows the transmission of downlink data between layers. As Figure 3A shown, from the perspective of the access network device, after the SDAP layer entity of the access network device obtains the data, it can map the data to the PDCP layer entity of the corresponding DRB according to the quality of service (QoS) flow identifier (QoS flow indicator, QFI) of the data. The PDCP layer entity can transmit the data to at least one RLC layer entity corresponding to the PDCP layer entity, and then the data is transmitted by at least one RLC layer entity to the corresponding MAC layer entity. The MAC layer entity generates a transport block, and then performs wireless transmission through the corresponding physical layer entity to send it to the terminal device.

[0101] Among them, the downlink data can be encapsulated correspondingly in each layer of the access network device. The data received by a certain layer from the upper layer of this layer is regarded as the service data unit (SDU) of this layer. After layer encapsulation, it becomes a PDU and is then passed to the next layer. For example, see Figure 3BAs shown, the data received by the PDCP layer entity from the SDAP layer can be referred to as PDCP SDU. After the PDCP layer entity encapsulates the PDCP SDU (such as adding a PDCP layer header), a PDCP PDU is obtained and sent to the RLC layer; the PDCP PDU received by the RLC layer entity from the PDCP layer can be referred to as RLC SDU. After the RLC layer entity encapsulates the RLC SDU (such as adding an RLC layer header), an RLC PDU is obtained and sent to the MAC layer; after receiving the RLC PDU, the MAC layer can encapsulate one or more RLC PDUs (and RLC PDU segments) into a MAC PDU. The MAC PDU can also be referred to as a transport block and the transport block is sent to the physical layer; after receiving the transport block, the physical layer can add check information, such as cyclic redundancy check (CRC), to the transport block and then send it to the terminal device. Among them, data can be transmitted between different layers through corresponding channels. For example, data can be transmitted between the RLC layer entity and the MAC layer entity through a logical channel (LCH), and data can be transmitted between the MAC layer entity and the physical layer entity through a transport channel.

[0102] When the access network device and the terminal device perform control plane signaling transmission, the signaling needs to pass through the control plane protocol layer, such as passing through the RRC layer, PDCP layer, RLC layer, MAC layer, and physical layer. Exemplarily, the access network device and the terminal device transmit signaling by establishing at least one signaling radio bearer (SRB). Among them, SRB and DRB can be collectively referred to as radio bearer (RB).

[0103] Taking the access network device sending RRC signaling to the terminal device as an example, among them, the RRC signaling can also be referred to as an RRC message. Figure 3A Schematically shows the schematic diagram of the RRC message transmission between layers. As Figure 3A shown, from the perspective of the access network device, after the RRC layer entity of the access network device generates an RRC message, the RRC message can be delivered to the PDCP layer entity of the corresponding SRB. The PDCP layer entity can transmit the RRC message to at least one RLC layer entity corresponding to the PDCP layer entity, and then be transmitted by at least one RLC layer entity to the corresponding MAC layer entity. Then the MAC layer entity generates a transport block, and then performs wireless transmission through the corresponding physical layer entity to send it to the terminal device.

[0104] From the perspective of the terminal device, after the physical layer of the terminal device receives the transport block from the access network device, it can deliver it layer by layer upwards from the physical layer, and corresponding de-encapsulation can be performed in each layer. That is to say, the processing performed by each layer in the terminal device can be the reverse process of the processing performed by each layer in the access network device.

[0105] The network architecture and service scenarios described in the embodiments of this application are to more clearly illustrate the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those of ordinary skill in the art know that with the evolution of the network architecture and the emergence of new service scenarios, the technical solutions provided by the embodiments of this application are equally applicable to similar technical problems.

[0106] Under a semantic communication framework based on joint source and channel coding (JSCC), the schedulable method is as follows:

[0107] Step 1: The application layer (or the source) performs semantic extraction on the original image x, assuming it is marked as vector y, and extracts the entropy estimation value of vector y.

[0108] Step 2: Guide physical layer channel coding and adaptive transmission by compromising data importance, redundancy, and channel transmission capabilities. For example, data with a higher entropy estimation value is allocated more bandwidth and a lower code rate during transmission, etc.

[0109] Specifically, at the sending end, the source information, such as the original image x, based on the category of the source, combines semantic information coding technology to extract semantic information, and inputs the semantic information (vector y) and transmission environment state information into the joint source-channel coding module. Based on the trained deep learning model, joint source-channel coding is performed on the above data information and sent to the physical channel for bit data transmission.

[0110] A corresponding receiver model is constructed at the receiving end. For example, the receiver model can include a joint source-channel decoder and a semantic decoder. First, the access end can decode the received bit data information based on the trained joint source-channel decoder and the current channel state information to obtain the corresponding semantic coding information. The receiving end inputs the semantic coding information into the semantic decoder to decode the corresponding semantic information and key feature extraction information. The receiving end verifies the semantic information. If the verification information passes, it indicates that the source information has been correctly transmitted; otherwise, repair is performed using the key feature information, or all the source information is triggered to be resent, or part of the source information is resent. When all the segmented semantic information is decoded, the overall semantic information is restored according to the segmentation method.

[0111] At present, source-channel joint coding usually requires the transmitting end to be able to perform source coding and channel coding simultaneously. In a hierarchical wireless communication system, the source and the channel belong to different entities of the network. The source is usually located at the application layer (such as a server), while the channel is located at the physical layer (such as a base station). How to apply source-channel joint coding to the current hierarchical wireless communication system urgently needs to be solved.

[0112] Based on this, an embodiment of the present application provides a communication method for implementing source-channel joint coding in a wireless communication system.

[0113] In the embodiments of the present application, when not specifically stated, "terminal device" may refer to the terminal device itself or a component in the terminal device, such as a chip or a chip system; "access network device" may refer to the access network device itself or a component in the access network device, such as a chip or a chip system. "Core network device" may refer to the core network device itself or a component in the core network device, such as a chip or a chip system.

[0114] In the present application, after the terminal device accesses the wireless network through the access network device, it can subscribe to one or more services. These one or more services may include semantic fault tolerance services, and optionally, non-semantic fault tolerance services.

[0115] The embodiments of the present application will be described in detail below in conjunction with the embodiments. The solutions of the present application will be introduced below taking the uplink scheduling and downlink scheduling as examples respectively. The difference between the uplink scheduling and the downlink scheduling is that in the uplink scheduling, the terminal device indicates the entropy estimation value to the access network device, and in the downlink scheduling, the core network device indicates the entropy estimation value to the access network device. The specific process is described in detail in Embodiment 1 and Embodiment 2 below.

[0116] It should be understood that Embodiment 1 and Embodiment 2 can be implemented separately or combined as a solution, and no specific limitation is made here.

[0117] It should be noted that the service data involved in Embodiment 1 is the service data from the terminal device, or it can also be understood as the service data generated by the terminal device (such as the application layer of the terminal device). The service data involved in Embodiment 1 can also be called uplink service data.

[0118] The service data involved in Embodiment 2 is the service data from the core network device, or it can also be understood as the service data generated by the core network device (such as the application layer of the core network device). The service data involved in Embodiment 2 can also be called downlink service data.

[0119] Embodiment 1: Taking the uplink scheduling as an example, Figure 4 is a schematic flowchart corresponding to a communication method provided by an embodiment of the present application. AsFigure 4 As shown, the method includes:

[0120] S401, the terminal device sends an entropy estimate of service data to the access network device. Correspondingly, the access network device receives the entropy estimate of the service data from the terminal device.

[0121] Wherein, the entropy estimate is used to characterize the distribution of the bit sequence of the service data in the service data. Alternatively, it can also be understood that the entropy estimate is used to measure the amount of information in the above service data. Wherein, the higher the entropy estimate, the more information in the above service data, and the lower the entropy estimate, the less information in the above service data.

[0122] In an exemplary illustration, the service data may include one or more bit sequences, and one bit sequence may correspond to one entropy estimate.

[0123] It should be understood that the bit sequence can also be described as a feature vector, a vector to be transmitted, a sequence to be transmitted, a data unit to be transmitted, semantic information, etc.

[0124] In a possible implementation, the entropy estimate may be carried in a buffer status report (BSR).

[0125] S402, the access network device sends scheduling information. Correspondingly, the terminal device receives the scheduling information.

[0126] Wherein, the scheduling information is used to configure resources for transmitting the above service data, and the scheduling information is related to the entropy estimate.

[0127] Exemplarily, the access network device may use the entropy estimate as input information to an uplink scheduler, and the scheduling information is the output information of the uplink scheduler. Wherein, the uplink scheduler is used to allocate resources for uplink transmission. In this application, the uplink scheduler may allocate resources for transmitting the above service data.

[0128] The input information and output information of the uplink scheduler are introduced below.

[0129] Regarding the input information of the uplink scheduler:

[0130] Optionally, the input information of the uplink scheduler may include one or more of the following information: relevant information of the terminal device, service data information, channel state information, power headroom report, or multiple-input multiple-output (MIMO) information.

[0131] Among them, the relevant information of the terminal device may include one or more of the following: terminal device capabilities, or the synchronization status of the terminal device, etc. The terminal device capabilities may refer to the maximum number of bits that can be transmitted per transmission time interval (TTI) corresponding to the above terminal device and the number of layers.

[0132] The service data information may include one or more of the following: the first scheduling request (SR), the BSR corresponding to the above service data, or the hybrid automatic repeat request (HARQ) feedback information, etc. The first SR is used to request resource allocation for the above service data.

[0133] Regarding the output information of the uplink scheduler:

[0134] Optionally, the output information of the uplink scheduler (i.e., the scheduling information) may include one or more of the following information: the scheduled terminal device, the cell beam set, the resource allocation information, the rank (RANK), the modulation and coding scheme (MCS), or the code rate. This application may assume that the scheduled terminal device includes Figure 4 the terminal device in the above method.

[0135] Among them, the cell beam set may include the transceiver channels and the analog beams on the transceiver channels.

[0136] The resource allocation information may include at least one of the following: the physical uplink shared channel (PUSCH) time-domain resource allocation information, the PUSCH frequency-domain resource allocation information, or the demodulation reference signal (DMRS) resource allocation information. Exemplarily, the PUSCH time-domain resource allocation information may indicate the time slot (slot) used to transmit the above service data, and the start and end positions of the orthogonal frequency division multiplexing (OFDM) symbols scheduled within the slot. The PUSCH frequency-domain resource allocation information may indicate the number of resource blocks (RBs) used to transmit the above service data and the RB positions. The DMRS resource allocation information may indicate the DMRS port resources used to transmit the above service data.

[0137] Exemplarily, the uplink scheduler may be as Figure 5 shown.

[0138] In a possible implementation, all or part of the above input information may be sent by a terminal device to an access network device.

[0139] As a possible way, the scheduling information may be determined by the MAC layer entity of the access network device. That is, the uplink scheduler may be located in the MAC layer entity of the access network device, and the uplink scheduler may also be referred to as the MAC scheduler.

[0140] If the access network device has a CU-DU split architecture, in this case, the terminal network device may send the information of the entropy estimation value to the DU, and the DU determines the scheduling information according to the entropy estimation value and sends it to the terminal device.

[0141] The following uses an example to illustrate the relationship between the scheduling information and the entropy estimation value.

[0142] Exemplarily, it is assumed that the scheduling information includes PUSCH frequency domain resource allocation information. The bandwidth (or the number of RBs) of the PUSCH frequency domain resource may be proportional to the entropy estimation value. The higher the entropy estimation value, the larger the bandwidth (or the number of RBs) of the frequency domain resource allocated by the access network device for this service data; the lower the entropy estimation value, the smaller the bandwidth (or the number of RBs) of the frequency domain resource allocated by the access network device for this service data. In this way, a larger bandwidth can be allocated for service data with a large amount of information, thereby improving the transmission rate, and a smaller bandwidth can also be allocated for service data with a small amount of information, thereby improving the resource utilization rate.

[0143] It is assumed that the scheduling information includes the coding rate. The coding rate may be inversely proportional to the entropy estimation value. The higher the entropy estimation value, the lower the coding rate allocated by the access network device for this service data; the lower the entropy estimation value, the higher the coding rate allocated by the access network device for this service data. In this way, a lower coding rate can be allocated for service data with a large amount of information, thereby ensuring data transmission and improving transmission performance, and a higher coding rate can also be allocated for service data with a small amount of information, thereby improving the resource utilization rate, which is beneficial for the terminal device and the access network device to save energy.

[0144] In the embodiments of the present application, the terminal device sends the entropy estimation value for source coding to the access network device, so that the access network device can perform scheduling according to the entropy estimation value. In this way, source-channel joint coding can be realized under the architecture of source-channel coding separation, and moreover, when the access network device performs data scheduling, considering the entropy estimation value can obtain a significant performance improvement.

[0145] Exemplarily, the method described in the present application may be applied to semantic fault-tolerant services, that is, the above service data is associated with semantic fault-tolerant services.

[0146] Optionally, the access network device may send a first message to the terminal device. The first message is used to configure the data radio bearer (DRB) and cell group configuration for the semantic fault tolerance service. Exemplarily, the cell group configuration may be a logical channel group (LCG). In this manner, if the above service data is associated with the semantic fault tolerance service, the terminal device may send the above service data to the access network device through the above DRB and cell group configuration.

[0147] Optionally, the access network device and the core network device may complete the establishment of a PDU session for the semantic fault tolerance service. In this manner, if the above service data is associated with the semantic fault tolerance service, the access network device may send the above service data to the core network device through this PDU session.

[0148] By configuring a separate PDU session, DRB, and cell group configuration for the semantic fault tolerance service in the above manner, it is possible to avoid sending the semantic fault tolerance service and the non-semantic fault tolerance service in the same PDU session, DRB, and cell group configuration. Since the two types of services have different quality requirements for transmission, such as different fault tolerance requirements for transmission, the communication performance can be further improved through the above manner.

[0149] As a possible implementation manner, if the above service data is associated with the semantic fault tolerance service, the terminal device may also indicate to the access network device that the above service data is associated with the semantic fault tolerance service. Three ways for the terminal device to indicate that the above service data is associated with the semantic fault tolerance service are introduced below.

[0150] Way A, the terminal device may indicate that the above service data is associated with the semantic fault tolerance service through a second SR. The second SR is used to request resources for transmitting the above input information.

[0151] Way B, the terminal device may indicate that the above service data is associated with the semantic fault tolerance service through a BSR.

[0152] Among them, the BSR may implicitly indicate that the above service data is associated with the semantic fault tolerance service. For example, the BSR may indicate that the LCG corresponding to the cache status is the LCG configured for the semantic fault tolerance service. For example, the identifier of the LCG carried by the BSR is the identifier of the LCG configured by the above first message. This manner can implicitly indicate that the above service data is associated with the semantic fault tolerance service by associating the LCG of the semantic fault tolerance service.

[0153] Alternatively, the BSR may also indicate a semantic fault-tolerant service associated with the above service data. For example, the BSR indicates whether the service data is associated with a semantic fault-tolerant service through the value status of a field / indicator field in its corresponding MAC subheader. For example, the MAC subheader of the BSR carries field 1. When the value of this field 1 is in the first status, it indicates that the service data is associated with a semantic fault-tolerant service. When the value of this field 1 is in the second status, it indicates that the service data is not associated with a semantic fault-tolerant service (or the service data is associated with a non-semantic fault-tolerant service). Another example is that the BSR indicates the above semantic fault-tolerant service associated with the service data by carrying a special field / indicator field in its corresponding MAC subheader. For example, if the MAC subheader of the BSR carries a special field / indicator field, it indicates that the service data is associated with a semantic fault-tolerant service. If the MAC subheader of the BSR does not carry the semantic fault-tolerant service associated with the service data, it indicates that the service data is not associated with a semantic fault-tolerant service (or the service data is associated with a non-semantic fault-tolerant service).

[0154] In Mode C, the terminal device may indicate the above semantic fault-tolerant service associated with the service data through the above entropy estimation value.

[0155] In this mode, the terminal device may send an entropy estimation value when the service data is associated with a semantic fault-tolerant service. Thus, if the access network device receives the entropy estimation value, it may determine that the above service data is associated with a semantic fault-tolerant service.

[0156] In addition, the terminal device may also indicate the above semantic fault-tolerant service associated with the service data through other means, which will not be elaborated here one by one.

[0157] It should be understood that the above three methods may be implemented separately to indicate the above semantic fault-tolerant service associated with the service data, or may be combined to indicate the above semantic fault-tolerant service associated with the service data. For example, when there is no resource for sending input information, the terminal device may send a second SR to the access network device, where the second SR may indicate a semantic fault-tolerant service associated with the service data. After the terminal device receives the response message of the second SR, it may send a BSR on the resource indicated by the response message, and the BSR may indicate a semantic fault-tolerant service associated with the service data. This method can improve the reliability of indicating the semantic fault-tolerant service associated with the service data through two indication processes.

[0158] Optionally, if the above service data is associated with a semantic fault-tolerant service, the above scheduling information may indicate that the configured resource is for the semantic fault-tolerant service.

[0159] The method for determining scheduling information based on the entropy estimation value is introduced above. The method for the terminal device to send service data after receiving the scheduling information is introduced below.

[0160] In a possible manner, the terminal device may send the above service data according to the scheduling information.

[0161] In a specific manner, the terminal device may maintain two sets of logical channel prioritization (LCP), where one set of LCP corresponds to (or is associated with) semantic fault-tolerant services, and the other set of LCP corresponds to (or is associated with) non-semantic fault-tolerant services. If the above service data is associated with semantic fault-tolerant services, the terminal device may send the service data according to the LCP corresponding to (or associated with) the semantic fault-tolerant services.

[0162] Alternatively, it can also be understood that the terminal device may maintain two token buckets, where one token bucket corresponds to (or is associated with) semantic fault-tolerant services, and the other token bucket corresponds to (or is associated with) non-semantic fault-tolerant services. The token bucket can be used to cache data. It should be understood that the token bucket can also be replaced with other names, which are not specifically limited here. If the above service data is associated with semantic fault-tolerant services, the terminal device may use the token bucket associated with the semantic fault-tolerant services to fill the data.

[0163] Through the above method, it is possible to prevent the data of semantic fault-tolerant services and the data of non-semantic fault-tolerant services from being filled into the same data block.

[0164] Optionally, if the above service data is associated with semantic fault-tolerant services, the access network device may not perform a physical layer cyclic redundancy check (CRC) on the service data after receiving it. Since semantic communication services can correctly decode the residual semantic information in the data packets with CRC errors, the above method can avoid discarding the data packets with CRC errors by skipping the CRC check process, thereby improving the transmission performance.

[0165] In a possible implementation manner, the access network device may enable the terminal device to report the entropy estimation value. For example, the access network device may send configuration information to the terminal device, and the configuration information is used to enable the reporting of the entropy estimation value. By way of example, the configuration information may enable the reporting of the entropy estimation value of the data of semantic fault-tolerant services.

[0166] "Enabling the reporting of the entropy estimation value" may also be described as "enabling / activating the function of reporting the entropy estimation value" or "activating the feature of reporting the entropy estimation value", etc., which are not specifically limited in this application.

[0167] In the embodiments of the present application, the terminal device sends the entropy estimation value for source coding to the access network device, enabling the access network device to perform scheduling based on the entropy estimation value. In this way, source-channel joint coding can be achieved under the architecture where source coding and channel coding are separated. Moreover, when the access network device performs data scheduling, it considers the entropy estimation value, resulting in a significant performance improvement. For example, a larger bandwidth and a lower code rate can be allocated to the data with a larger amount of information (i.e., a larger entropy estimation value), and a smaller bandwidth and a higher code rate can be allocated to the data with a smaller amount of information (i.e., a smaller entropy estimation value), thereby enabling variable-rate transmission.

[0168] The above content introduced the solution of the present application by taking the uplink scheduling as an example. Next, the solution of the present application will be introduced by taking the downlink scheduling as an example.

[0169] Embodiment 2: Figure 6 It is a schematic flowchart corresponding to a communication method provided by an embodiment of the present application. As Figure 6 shown, the method includes:

[0170] S601, the core network device sends the information of the entropy estimation value to the access network device. Correspondingly, the access network device receives the information of the entropy estimation value.

[0171] Among them, the entropy estimation value is used to characterize the distribution of the bit sequence of the service data in the service data. For the specific description of the entropy estimation value, reference can be made to the relevant description of the entropy estimation value in Embodiment 1.

[0172] In an exemplary illustration, the service data may include one or more bit sequences, and one bit sequence may correspond to one entropy estimation value. It should be understood that the bit sequence can also be described as a feature vector, a vector to be transmitted, a sequence to be transmitted, etc.

[0173] In a possible implementation manner, the information of the entropy estimation value may be the entropy estimation value itself, that is, the core network device may send the entropy estimation value to the access network device. Correspondingly, the access network device receives the entropy estimation value from the core network device.

[0174] In another possible implementation manner, the information of the entropy estimation value may include the entropy estimation model and the service data from the core network device, that is, the core network device may send the entropy estimation model and the service data to the access network device. Correspondingly, the access network device receives the entropy estimation model and the service data from the core network device. In this implementation manner, the access network device can determine the entropy estimation value according to the service data and the entropy estimation model from the core network device. It should be noted that the present application does not limit the sending order of the entropy estimation model and the service data.

[0175] S602, the access network device sends scheduling information to the terminal device. Correspondingly, the terminal device receives the scheduling information from the access network device.

[0176] Among them, the scheduling information is used to configure resources for transmitting the above service data, and the scheduling information is related to the entropy estimation value.

[0177] Exemplarily, the access network device may use the entropy estimation value as the input information of the downlink scheduler, and the scheduling information is the output information of the downlink scheduler. Among them, the downlink scheduler is used to allocate resources for downlink transmission. In this application, the downlink scheduler may allocate resources for transmitting the above service data.

[0178] The input information and output information of the downlink scheduler are introduced below.

[0179] Regarding the input information of the downlink scheduler:

[0180] Optionally, the input information of the downlink scheduler may include one or more of the following information: relevant information of the access network device and the terminal device, service data information, channel state information, or downlink power information.

[0181] Among them, the relevant information of the access network device and the terminal device may include at least one of the following: downlink (DL) bandwidth part (BWP) configuration, synchronization state of the terminal device, number of receiving antennas and transmitting antennas of the access network device, or number of receiving antennas and transmitting antennas of the terminal device.

[0182] The service data information may include one or more of the following: buffer amount of the above service data, or HARQ feedback information.

[0183] The channel state information may include one or more of the following: precoding matrix indicator (PMI), channel quality indicator (CQI), rank indicator (RI), or beam gain.

[0184] The downlink power information includes the transmit power of all scheduled terminal devices in the cell corresponding to the access network device.

[0185] Regarding the output information of the downlink scheduler:

[0186] Optionally, the output information (or scheduling information) of the downlink scheduler may include one or more of the following information: scheduled terminal device, cell beam set, resource allocation information, RANK, MCS, or code rate. This application may assume that the scheduled terminal device includes Figure 6 the terminal device in the above method.

[0187] Among them, the cell beam set may include a transceiver channel and an analog beam on the transceiver channel.

[0188] The resource allocation information may include at least one of the following: physical downlink shared channel (PDSCH) time domain resource allocation information, PDSCH frequency domain resource allocation information, or DMRS resource allocation information. Among them, the PDSCH time domain resource allocation information, PDSCH frequency domain resource allocation information, and DMRS resource allocation information are similar to the PUSCH time domain resource allocation information, PUSCH frequency domain resource allocation information, and DMRS resource allocation information in Embodiment 1. For specific details, reference can be made to the relevant descriptions in Embodiment 1, and no further description will be provided here.

[0189] Exemplarily, the downlink scheduler may be as Figure 7 shown.

[0190] As a possible way, the scheduling information may be determined by the MAC layer entity of the access network device, that is, the downlink scheduler may be located in the MAC layer entity of the access network device, and the downlink scheduler may also be referred to as a MAC scheduler.

[0191] If the access network device has a CU-DU separated architecture, in this method, the core network device may send the information of the entropy estimation value to the CU, the CU sends the entropy estimation value to the DU through the FI interface, and the DU determines the scheduling information according to the entropy estimation value and sends it to the terminal device.

[0192] The relationship between the scheduling information and the entropy estimation value will be illustrated by examples below.

[0193] Exemplarily, it is assumed that the scheduling information includes PDSCH frequency domain resource allocation information. The relationship between the bandwidth (or the number of RBs) of the PDSCH frequency domain resource and the entropy estimation value is similar to the relationship between the bandwidth (or the number of RBs) of the PUSCH frequency domain resource and the entropy estimation value in Embodiment 1. For specific details, reference can be made to the relevant descriptions in Embodiment 1, and no further description will be provided here.

[0194] It is assumed that the scheduling information includes the code rate. The relationship between the code rate and the entropy estimation value is similar to the relationship between the code rate and the entropy estimation value in Embodiment 1. For specific details, reference can be made to the relevant descriptions in Embodiment 1, and no further description will be provided here.

[0195] In the embodiments of the present application, the core network device sends the entropy estimation value for source coding to the access network device, so that the access network device can perform scheduling according to the entropy estimation value. Through this method, source-channel joint coding can be realized in an architecture with separated source-channel coding. Moreover, when the access network device performs data scheduling and considers the entropy estimation value, a significant performance improvement can be obtained.

[0196] Exemplarily, the method described in this application can be applied to semantic fault tolerance services, that is, the above service data is associated with semantic fault tolerance services.

[0197] In a possible implementation, the core network device can also send the above service data to the access network device. The access network device can send the above service data to the terminal device according to the above scheduling information.

[0198] Optionally, before S601, the access network device and the core network device can complete the establishment of a PDU session for semantic fault tolerance services. In this way, if the above service data is associated with semantic fault tolerance services, the core network device can send the above service data to the access network device through this PDU session.

[0199] Optionally, the access network device can send a second message to the terminal device. The second message is used to configure the DRB and cell group configuration for semantic fault tolerance services. Exemplarily, the cell group configuration can be LCG. In this way, if the above service data is associated with semantic fault tolerance services, the access network device can send the above service data to the terminal device through the above DRB and cell group configuration.

[0200] In a possible implementation, the PDU session, the DRB of the semantic fault tolerance service, and the cell group configuration in the second embodiment can be the same as those in the first embodiment. That is, the PDU session established between the core network device and the access network device can be used to transmit the service data in the first embodiment and can also be used to transmit the service data in the second embodiment. The DRB and cell group configuration configured by the access network device can be used to transmit the service data in the first embodiment and can also be used to transmit the service data in the second embodiment.

[0201] The above method configures a separate PDU session, DRB, and cell group configuration for semantic fault tolerance services, thereby avoiding the transmission of semantic fault tolerance services and non-semantic fault tolerance services in the same PDU session, DRB, and cell group configuration.

[0202] In the embodiments of this application, the core network device sends the entropy estimation value for source coding to the access network device, so that the access network device can perform scheduling according to the entropy estimation value. Through this method, source-channel joint coding can be achieved in an architecture with separated source-channel coding. Moreover, when the access network device performs data scheduling, it considers the entropy estimation value and obtains a significant performance improvement. For example, a larger bandwidth and a lower code rate can be allocated for a larger amount of information (i.e., a larger entropy estimation value), and a smaller bandwidth and a higher code rate can be allocated for a smaller amount of information (i.e., a smaller entropy estimation value), thereby enabling variable-rate transmission.

[0203] Based on the same inventive concept as the method embodiments, an embodiment of the present application provides a communication device, and the structure of the communication device may be as follows Figure 8 shown, including a communication unit 801 and a processing unit 802.

[0204] In one embodiment, the communication device may specifically be used to implement Figure 4 the method executed by the terminal device in the embodiments, and the device may be the terminal device itself, or a chip or chipset in the terminal device, or a part of the chip for executing the relevant method functions. Among them, the processing unit 802 is configured to send an entropy estimate value of service data to an access network device through the communication unit 801, and the entropy estimate value is used to characterize the distribution of the bit sequence of the service data in the service data; and, receive scheduling information from the access network device through the communication unit 801, where the scheduling information is used to configure resources for transmitting the service data, and the scheduling information is related to the entropy estimate value.

[0205] Optionally, the processing unit 802 is further configured to send a scheduling request through the communication unit 801 before sending the entropy estimate value of the service data, where the scheduling request indicates that the service data is associated with a semantic fault-tolerant service.

[0206] Optionally, the processing unit 802 is further configured to send a buffer status report through the communication unit 801, where the buffer status report indicates that the service data is associated with a semantic fault-tolerant service.

[0207] Optionally, the processing unit 802 is further configured to send the service data through the communication unit 801 according to the logical channel priority associated with the semantic fault-tolerant service.

[0208] Optionally, the processing unit 802 is further configured to receive a first message through the communication unit 801, where the first message is used to configure a data radio bearer and a logical channel group for the semantic fault-tolerant service, and the service data is associated with the semantic fault-tolerant service.

[0209] Optionally, the processing unit 802 is further configured to receive configuration information through the communication unit 801, where the configuration information is used to enable reporting of the entropy estimate value.

[0210] In one embodiment, the communication device may specifically be used to implement Figure 4 the method executed by the access network device in the embodiments, and the device may be the access network device itself, or a chip or chipset in the access network device, or a part of the chip for executing the relevant method functions. Among them, the processing unit 802 is configured to receive an entropy estimate value from the terminal device through the communication unit 801, and the entropy estimate value is used to characterize the distribution of the bit sequence of the service data in the service data; and, send scheduling information to the terminal device through the communication unit 801, where the scheduling information is used to configure resources for transmitting the service data, and the scheduling information is determined according to the entropy estimate value.

[0211] Optionally, the processing unit 802 is further configured to receive a scheduling request through the communication unit 801 before receiving the entropy estimation value of the service data, where the scheduling request indicates that the service data is associated with a semantic fault tolerance service.

[0212] Optionally, the processing unit 802 is further configured to receive a buffer status report through the communication unit 801, where the buffer status report indicates that the service data is associated with a semantic fault tolerance service.

[0213] Optionally, the processing unit 802 is further configured to send a first message through the communication unit 801 before sending the entropy estimation value of the service data, where the first message is used to configure the data radio bearer and logical channel group of the semantic fault tolerance service.

[0214] Optionally, the processing unit 802 is further configured to send configuration information through the communication unit 801, where the configuration information is used to enable reporting of the entropy estimation value.

[0215] In one embodiment, the communication device may specifically be used to implement Figure 6 the method performed by the access network device in the embodiment of , where the device may be the access network device itself, or a chip or chip group in the access network device, or a part of the chip for performing the relevant method functions. Among them, the processing unit 802 is configured to receive information about the entropy estimation value from the core network device, where the entropy estimation value is used to characterize the distribution of the bit sequence of the service data in the service data; and send scheduling information to the terminal device through the communication unit 801, where the scheduling information is used to configure resources for transmitting the service data, and the scheduling information is determined according to the entropy estimation value.

[0216] Optionally, the processing unit 802 is further configured to send a first message through the communication unit 801, where the first message is used to configure the data radio bearer and logical channel group of the semantic fault tolerance service, and the service data is associated with the semantic fault tolerance service.

[0217] In one embodiment, the communication device may specifically be used to implement Figure 6 the method performed by the core network device in the embodiment of , where the device may be the core network device itself, or a chip or chip group in the core network device, or a part of the chip for performing the relevant method functions. Among them, the processing unit 802 is configured to determine information about the entropy estimation value, where the entropy estimation value is used to characterize the distribution of the bit sequence of the service data in the service data; and the communication unit 801 is configured to send information.

[0218] In the embodiments of the present application, the division of modules is illustrative, merely a logical function division. In actual implementation, there may be other division methods. Additionally, in each embodiment of the present application, each functional module may be integrated in a processor, may exist independently physically, or two or more modules may be integrated in one module. The above integrated modules may be implemented in the form of hardware or in the form of software functional modules. It can be understood that the functions or implementations of each module in the embodiments of the present application may be further referred to the relevant descriptions of the method embodiments.

[0219] In one possible way, the communication device may be as Figure 9 shown. This device may be a communication device or a chip in a communication device, where the communication device may be the terminal device in the above embodiments or the network device in the above embodiments. The device includes a processor 901 and a communication interface 902, and may further include a memory 903. Among them, the processing unit 802 may be the processor 901. The communication unit 801 may be the communication interface 902. Optionally, the processor 901 and the memory 903 may also be integrated together.

[0220] The processor 901 may be a CPU, or a digital processing unit, etc. The communication interface 902 may be a transceiver, may also be an interface circuit such as a transceiver circuit, or may be a transceiver chip, etc. The device further includes: a memory 903 for storing the program executed by the processor 901. The memory 903 may be a non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), etc., or may also be a volatile memory, such as a random-access memory (RAM). The memory 903 is any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto.

[0221] The processor 901 is used to execute the program code stored in the memory 903, specifically for performing the actions of the above processing unit 802, which will not be elaborated herein in the present application. The communication interface 902 is specifically used to perform the actions of the above communication unit 801, which will not be elaborated herein in the present application.

[0222] In the embodiments of the present application, the specific connection medium between the above communication interface 902, processor 901, and memory 903 is not limited. In the embodiments of the present application Figure 9 it is connected by a bus 904 between the memory 903, processor 901, and communication interface 902. The bus is in Figure 9The middle is represented by a thick line. The connection manners between other components are only for illustrative purposes and are not restrictive. The bus can be divided into an address bus, a data bus, a control bus, etc. For the convenience of representation, Figure 9 only a thick line is used to represent it in the figure, but it does not mean that there is only one bus or one type of bus.

[0223] The embodiment of the present invention also provides a computer-readable storage medium for storing computer software instructions required to be executed by the above-mentioned processor, and it includes a program required to be executed by the above-mentioned processor.

[0224] The embodiment of the present application also provides a communication system, including a communication device for implementing Figure 4 the functions of the terminal device in the embodiment of Figure 4 and a communication device for implementing the functions of the access network device in the embodiment of

[0225] The embodiment of the present application also provides a communication system, including a communication device for implementing Figure 6 the functions of the core network device in the embodiment of Figure 6 and a communication device for implementing the functions of the access network device in the embodiment of

[0226] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0227] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each process and / or block in the flowchart and / or block diagram can be implemented by computer program instructions, and the combination of the processes and / or blocks in the flowchart and / or block diagram can also be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for implementing the specified functions in Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0228] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement the function specified in the flowchart(s) Figure 1 a flowchart or flowcharts and / or block(s) Figure 1 a block or blocks specified therein.

[0229] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable apparatus provide steps for implementing the function specified in the flowchart(s) Figure 1 a flowchart or flowcharts and / or block(s) Figure 1 a block or blocks specified therein.

[0230] It will be apparent to those skilled in the art that various modifications and variations can be made to the present application without departing from the scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application is also intended to cover these modifications and variations.

Claims

1. A communication method, characterized in that, the method is applied to a terminal device, and the method includes: sending an entropy estimate value of service data to an access network device, where the entropy estimate value is used to characterize the distribution of the bit sequence of the service data in the service data; receiving scheduling information from the access network device, where the scheduling information is used to configure resources for transmitting the service data, and the scheduling information is related to the entropy estimate value.

2. The method according to claim 1, characterized in that, before sending the entropy estimate value of the service data, the method further includes: sending a scheduling request, where the scheduling request indicates that the service data is associated with a semantic fault-tolerant service.

3. The method according to claim 1 or 2, characterized in that, the method further includes: sending a buffer status report, where the buffer status report indicates that the service data is associated with a semantic fault-tolerant service.

4. The method according to any one of claims 1-3, characterized in that, the entropy estimate value is carried in the buffer status report.

5. The method according to any one of claims 1-4, characterized in that, the scheduling information indicates that the configured resources are for a semantic fault-tolerant service.

6. The method according to any one of claims 1-5, characterized in that, the method further includes: sending the service data according to the logical channel priority associated with the semantic fault-tolerant service.

7. The method according to any one of claims 1-6, characterized in that, the method further includes: receiving a first message, where the first message is used to configure a data radio bearer and a logical channel group for the semantic fault-tolerant service, and the service data is associated with the semantic fault-tolerant service.

8. The method according to any one of claims 1-7, characterized in that, the method further includes: receiving configuration information, where the configuration information is used to enable reporting of the entropy estimate value.

9. A communication method, characterized in that, the method is applied to an access network device, and the method includes: receiving an entropy estimate value from a terminal device, where the entropy estimate value is used to characterize the distribution of the bit sequence of service data in the service data; sending scheduling information to the terminal device, where the scheduling information is used to configure resources for transmitting the service data, and the scheduling information is determined according to the entropy estimate value.

10. The method according to claim 9, characterized in that, before receiving the entropy estimate value of the service data, the method further includes: receiving a scheduling request, where the scheduling request indicates that the service data is associated with a semantic fault-tolerant service.

11. The method according to claim 9 or 10, characterized in that, the method further includes: receiving a buffer status report, where the buffer status report indicates that the service data is associated with a semantic fault-tolerant service.

12. The method according to any one of claims 9-11, characterized in that, the entropy estimate value is carried in the buffer status report.

13. The method according to any one of claims 9-12, characterized in that, the scheduling information indicates that the configured resources are for a semantic fault-tolerant service.

14. The method according to any one of claims 9-13, characterized in that, before sending the entropy estimate value of the service data, the method further includes: Send a first message, where the first message is used to configure the data radio bearer and logical channel group of the semantic fault tolerance service.

15. The method according to any one of claims 9-14, wherein, the method further includes: Sending configuration information, where the configuration information is used to enable reporting of the entropy estimation value.

16. A communication method, wherein, the method is applied to an access network device, and the method includes: Receiving information on the entropy estimation value from a core network device, where the entropy estimation value is used to characterize the distribution of the bit sequence of service data in the service data; Sending scheduling information to a terminal device, where the scheduling information is used to configure resources for transmitting the service data, and the scheduling information is determined according to the entropy estimation value.

17. The method according to claim 16, wherein, the information on the entropy estimation value is the entropy estimation value; or, the information on the entropy estimation value includes an entropy estimation value model and service data.

18. The method according to claim 16 or 17, wherein, the scheduling information indicates that the configured resources are for the semantic fault tolerance service.

19. The method according to any one of claims 16-18, wherein, the method further includes: Sending a first message, where the first message is used to configure the data radio bearer and logical channel group of the semantic fault tolerance service, and the service data is associated with the semantic fault tolerance service.

20. A communication method, wherein, the method is applied to a core network device, and the method includes: Determining information on the entropy estimation value, where the entropy estimation value is used to characterize the distribution of the bit sequence of service data in the service data; Sending the information.

21. The method according to claim 20, wherein, the information is the entropy estimation value; or, the information includes an entropy estimation value model and service data.

22. A communication device, wherein, includes units or modules for executing the method according to any one of claims 1 to 8, or includes units or modules for executing the method according to any one of claims 9-15, or includes units or modules for executing the method according to any one of claims 16-19, or includes units or modules for executing the method according to claim 20 or 21.

23. A communication device, wherein, includes a processor and a memory, the memory is used to store program instructions, and when the processor executes the program instructions, the method according to any one of claims 1 to 8 is executed, or the method according to any one of claims 9-15 is executed, or the method according to any one of claims 16-19 is executed, or the method according to claim 20 or 21 is executed.

24. A computer-readable storage medium, wherein, The computer storage medium stores computer-readable instructions that, when run on a communication device, cause the method according to any one of claims 1 to 8, or the method according to any one of claims 9 to 15, or the method according to any one of claims 16 to 19, or the method according to claim 20 or 21 to be executed.

25. A computer program product, characterized in that when the computer program product runs on a device, the device is caused to execute the method according to any one of claims 1 to 8, or the method according to any one of claims 9 to 15, or the method according to any one of claims 16 to 19, or the method according to claim 20 or 21.

Images