Communication method and apparatus

Abstract

The present application provides a communication method and apparatus, which are used for implementing joint source-channel 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, wherein the entropy estimation value is used for representing a distribution of a bit sequence of the service data in the service data, the scheduling information is used for configuring resources for transmitting the service data, and the scheduling information is related to the entropy estimation value. In this way, joint source-channel coding can be achieved under an architecture of separate source-channel coding, and the access network device considers the entropy estimation value during data scheduling, so that a large performance improvement can be achieved.

Description

Communication method and device

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on November 30, 2023, with application number 202311636817.3 and application name “A Communication Method”, the entire contents of which are incorporated by reference into this application. Technical Field

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

[0004] In recent years, with the demand for improved communication efficiency in the 5G and 6G eras, and the widespread application of artificial intelligence in various fields, semantic communication technology based on deep learning has become a viable solution to the bottlenecks of traditional information transmission. Compared to traditional communication technologies that encode the source information before transmission, semantic communication technology encodes the semantic information extracted from the source information before transmission. Existing research shows that semantic communication has higher communication efficiency and is more resilient to channel interference. The semantic communication system is an end-to-end system composed of modules such as semantic encoding, source-channel joint encoding, source-channel joint decoding, and semantic decoding. It is used for semantic communication of multimodal information such as images / video, text, and voice. Specifically, source-channel joint coding enables variable-rate transmission of semantic communication, resulting in significant performance improvements.

[0005] 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. Therefore, how to apply joint source-channel coding in wireless communication systems needs to be urgently addressed. Summary of the Invention

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

[0007] In a first aspect, a communication method is provided, wherein the execution subject 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 value of service data to an access network device, and receiving scheduling information from the access network device, wherein the entropy estimate value is used to characterize the distribution of the 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 value.

[0008] In the embodiments of the present application, the terminal device transmits the entropy estimate used for source coding to the access network device, allowing the access network device to perform scheduling based on the entropy estimate. This approach enables joint source-channel coding within an architecture where source-channel coding is separated. Furthermore, the access network device considers the entropy estimate when performing data scheduling, significantly improving performance.

[0009] In one possible design, a scheduling request can be sent before sending the entropy estimate for the service data. The scheduling request indicates that the service data is associated with a semantically fault-tolerant service. This design allows the access network device to be requested to allocate resources dedicated to the semantically fault-tolerant service, thereby preventing semantically fault-tolerant and non-semantically fault-tolerant services from using the same resources for data transmission.

[0010] In one possible design, the method further includes: sending a buffer status report, wherein 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 conducive to improving communication performance.

[0011] In one possible design, the entropy estimate is carried in the buffer status report.

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

[0013] In one possible design, the method further includes: sending service data according to the logical channel priority associated with the semantic error-tolerant service. This method can avoid the data of the semantic error-tolerant service and the data of the non-semantic error-tolerant service from being filled into the same data block.

[0014] In one possible design, the method further includes receiving a first message, the first message being used to configure a data radio bearer and a logical channel group for a semantic fault-tolerant service, wherein 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, the above approach avoids sending the semantic fault-tolerant service and non-semantic fault-tolerant service in the same data radio bearer and logical channel group.

[0015] In one possible design, the method further includes: receiving configuration information, where the configuration information is used to enable reporting of the entropy estimate value. The above design can flexibly control the terminal device to report the entropy estimate value.

[0016] On the second aspect, a communication method is provided, the execution subject of the method can be an access network device or a chip, chip system or circuit located in the access network device, and the method can be implemented by the following steps: receiving an entropy estimation value from a terminal device, 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, the scheduling information is used to configure resources for transmitting the service data, and the scheduling information is determined based on the entropy estimation value.

[0017] In the embodiments of the present application, the terminal device transmits the entropy estimate used for source coding to the access network device, allowing the access network device to perform scheduling based on the entropy estimate. This approach enables joint source-channel coding within an architecture where source-channel coding is separated. Furthermore, the access network device considers the entropy estimate when performing data scheduling, significantly improving performance.

[0018] In one possible design, a scheduling request can be received before receiving the entropy estimate for the service data. The scheduling request indicates that the service data is associated with a semantically fault-tolerant service. This design allows the access network device to be requested to allocate resources dedicated to the semantically fault-tolerant service, thereby preventing semantically fault-tolerant and non-semantically fault-tolerant services from using the same resources for data transmission.

[0019] In one possible design, the method further includes: receiving a buffer status report, wherein 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 conducive to improving communication performance.

[0020] In one possible design, the entropy estimate is carried in the buffer status report.

[0021] In one possible design, the scheduling information indicates that the configured resources are used for semantic fault-tolerant services.

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

[0023] In one possible design, the method also includes: sending configuration information, where the configuration information is used to enable reporting of the entropy estimate.

[0024] According to a third aspect, a communication method is provided, wherein the executing subject of the method may be an access network device or a chip, chip system or circuit located in the access network device, and the method may be implemented by the following steps: receiving information on an entropy estimation value from a core network device, the entropy estimation value being used to characterize the distribution of a bit sequence of service data in the service data; and sending scheduling information to a terminal device, the scheduling information being used to configure resources for transmitting service data, and the scheduling information being determined based on the entropy estimation value.

[0025] In the embodiments of the present application, the core network device transmits the entropy estimate used for source coding to the access network device, allowing the access network device to perform scheduling based on the entropy estimate. This approach enables joint source-channel coding in an architecture with separate source-channel coding. Furthermore, the access network device considers the entropy estimate when performing data scheduling, significantly improving performance.

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

[0027] In one possible design, the entropy estimate information includes an entropy estimate model and service data. With this design, the core network device need not send the entropy estimate model in subsequent downlink transmission scheduling, thereby reducing signaling overhead between the access network device and the core network device.

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

[0029] In one 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 a semantic fault-tolerant service, wherein 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, the above approach avoids sending the semantic fault-tolerant service and non-semantic fault-tolerant service in the same data radio bearer and logical channel group.

[0030] In a fourth aspect, a communication method is provided, wherein the execution subject of the method may be a core network device or a chip, chip system or circuit located in the core network device, and the method may be implemented through the following steps: determining information of an entropy estimation value, the entropy estimation value being used to characterize the distribution of a bit sequence of service data in the service data; and sending information.

[0031] In the embodiments of the present application, the core network device transmits the entropy estimate used for source coding to the access network device, allowing the access network device to perform scheduling based on the entropy estimate. This approach enables joint source-channel coding in an architecture with separate source-channel coding. Furthermore, the access network device considers the entropy estimate when performing data scheduling, significantly improving performance.

[0032] In one possible design, the information is an entropy estimate. The above design can save computing resources of the access network device and reduce energy consumption of the access network device by directly indicating the entropy estimate.

[0033] In one possible design, the information includes the entropy estimation model and service data. With the above design, the core network device does not need to send the entropy estimation model in subsequent downlink transmission scheduling, thereby reducing signaling overhead between the access network device and the core network device.

[0034] 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 in hardware or by hardware executing corresponding software implementations. The hardware or software includes one or more units or modules corresponding to the above functions.

[0035] In one 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 method described above. The communication device may also include a memory, which may be coupled to the processor and stores program instructions and data necessary for the communication device. Optionally, the communication device also includes an interface circuit for supporting communication between the communication device and equipment such as a service satellite, such as the transmission and reception of data or signals. Exemplarily, the communication interface may be a transceiver, circuit, bus, module, or other type of communication interface.

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

[0037] In one possible design, the structure of the communication device includes a processing unit and a communication unit, which can perform the corresponding functions in the above method example. For details, please refer to the description of the method provided in the first aspect, which will not be repeated here.

[0038] 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 or third aspects above. The communication device can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more units or modules corresponding to the above functions.

[0039] In one 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 method shown above. The communication device may also include a memory, which may be coupled to the processor and stores the necessary program instructions and data for the communication device. Optionally, the communication device also includes an interface circuit, which is used to support communication between the communication device and devices such as terminal devices and core network devices, such as the transmission and reception of data or signals. Exemplarily, the communication interface may be a transceiver, circuit, bus, module, or other type of communication interface.

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

[0041] In one possible design, the structure of the communication device includes a processing unit and a communication unit, which can perform the corresponding functions in the above method examples. For details, please refer to the description of the method provided in the second aspect or the third aspect, which will not be repeated here.

[0042] In a seventh aspect, the present application further provides a communications device, which is a core network device or a chip in a core network device. The communications device has the functionality to implement any of the methods provided in the fourth aspect above. The communications device can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more units or modules corresponding to the above-mentioned functions.

[0043] In one possible design, the communication device includes: a processor configured to support the communication device in executing the corresponding functions of the core network device in the method shown above. The communication device may also include a memory, which may be coupled to the processor and stores the necessary program instructions and data for the communication device. Optionally, the communication device also includes an interface circuit, which is used to support communication between the communication device and an access network device, such as the transmission and reception of data or signals. Exemplarily, the communication interface may be a transceiver, circuit, bus, module, or other type of communication interface.

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

[0045] In one possible design, the structure of the communication device includes a processing unit and a communication unit, which can perform the corresponding functions in the above method example. For details, please refer to the description of the method provided in the fourth aspect, which will not be repeated here.

[0046] In an eighth aspect, a communication device is provided, comprising a processor and an interface circuit, wherein 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, and the processor is used to implement the method in the aforementioned first aspect and any possible design through logic circuits or execution code instructions.

[0047] In the ninth aspect, a communication device is provided, comprising a processor and an interface circuit, the interface circuit being used to receive signals from other communication devices outside the communication device and transmit them to the processor or to send signals from the processor to other communication devices outside the communication device, the processor being used to implement the methods in the aforementioned second aspect or third aspect and any possible design through logic circuits or execution code instructions.

[0048] In the tenth aspect, a communication device is provided, comprising a processor and an interface circuit, the interface circuit being used to receive signals from other communication devices outside the communication device and transmit them to the processor or to send signals from the processor to other communication devices outside the communication device, the processor being used to implement the method in the aforementioned fourth aspect and any possible design through logic circuits or execution code instructions.

[0049] In the eleventh aspect, a computer-readable storage medium is provided, which stores a computer program or instruction. When the computer program or instruction is executed by a processor, the method of any one of the first to fourth aspects and any possible design is implemented.

[0050] In a twelfth aspect, a computer program product storing instructions is provided, which, when executed by a processor, implements the methods in the aforementioned first to fourth aspects and any possible designs.

[0051] In a thirteenth aspect, a chip system is provided, comprising a processor and a memory, for implementing the methods of the first through fourth aspects and any possible designs. The chip system may consist of a chip alone or may include a chip and other discrete components.

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

[0053] In a fifteenth aspect, a communication system is provided, the system comprising the apparatus described in the third aspect (such as an access network device) and the apparatus described in the fourth aspect (such as a core network device). Optionally, the system may further comprise a terminal device.

[0054] The technical effects that can be achieved by the technical solutions of any of the above-mentioned fifth to fifteenth aspects can be described with reference to the technical effects that can be achieved by the technical solutions of the above-mentioned first to fourth aspects, and the repetitions will not be repeated. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] FIG1 is a schematic diagram of the architecture of a communication system according to an embodiment of the present application;

[0056] FIG2A is a diagram illustrating an example of a protocol layer structure according to an embodiment of the present application;

[0057] FIG2B is a diagram illustrating an example of a data packet structure according to an embodiment of the present application;

[0058] FIG3A is a schematic diagram of downlink data transmission according to an embodiment of the present application;

[0059] FIG3B is a diagram illustrating an exemplary data packet encapsulation structure according to an embodiment of the present application;

[0060] FIG4 is a flow chart of a communication method according to an embodiment of the present application;

[0061] FIG5 is a schematic diagram of an uplink scheduler according to an embodiment of the present application;

[0062] FIG6 is a flow chart of a communication method according to an embodiment of the present application;

[0063] FIG7 is a schematic diagram of a downlink scheduler according to an embodiment of the present application;

[0064] FIG8 is a schematic structural diagram of a communication device according to an embodiment of the present application;

[0065] FIG9 is a schematic structural diagram of a communication device according to an embodiment of the present application. DETAILED DESCRIPTION

[0066] Below, some terms used in the embodiments of the present application are explained to facilitate understanding by those skilled in the art.

[0067] 1. Semantic Communication: Unlike traditional communication, where the primary goal is to accurately transmit information at the bit or symbol level, and therefore the bit error rate (BER) or symbol error rate (SER) serves as its primary performance metric, semantic communication focuses on how accurately the transmitted symbols convey the intended meaning. Some current video applications incorporate forward error correction (FEC) at the application layer to achieve fault tolerance. Fault tolerance can be understood as follows: the transmitter encodes the original information vector A into a latent representation vector B within a specified semantic feature domain. This is transmitted over the air interface, and the receiver receives the latent representation vector B', where B ≠ B'. However, within this semantic feature domain, the Hamming distance between the latent representation vector B' received by the receiver and the latent representation vector B at the transmitter does not exceed a specified threshold ε. The receiver can decode the received latent representation vector B' into A', where A' = A. In this case, the fault tolerance can be quantified as ε.

[0068] 2. Semantic Fault-Tolerant Services: Also known as fault-tolerant services, semantic fault-tolerant services refer to services where the source or application layer decoding is fault-tolerant, meaning that the source or application layer can recover the correct content based on erroneous data.

[0069] Alternatively, semantic error tolerance can be achieved by adding forward error correction (FEC) at the application layer. FEC allows for transmission errors in received data, but in certain scenarios, such as when the number of erroneous bits is relatively small and still within the error correction capability, the application layer can use FEC to correct the erroneous data and recover the correct content.

[0070] Alternatively, semantic fault tolerance services can also use artificial intelligence (AI) decoding. From an information theory perspective, because AI decoding models can provide additional information entropy, even if some information entropy is lost when data is transmitted incorrectly, AI decoding can still replenish the lost information entropy, allowing the information content to be correctly restored.

[0071] It should be noted that "semantic fault-tolerant service" is only an exemplary name. This application does not limit the naming of this type of service. In specific implementation, as long as the service can be correctly decoded based on erroneous data packets, it can be understood as the semantic fault-tolerant service described in this application.

[0072] 3. Entropy estimate: This can also be called entropy value, information entropy, etc. In information theory, entropy estimates reflect the uncertainty of information. A larger entropy estimate for business data indicates richer information. Conversely, a smaller entropy estimate indicates less information.

[0073] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0074] 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, fifth generation (5G) mobile communication system, such as new radio (NR) system, and future evolved communication systems, such as sixth generation (6G) mobile communication system.

[0075] In particular, the embodiments of the present application may be applicable to semantic communication systems.

[0076] This 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 schemes may also be used. In addition, in the embodiments of this application, words such as "exemplarily" and "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described in this application as an "example" should not be interpreted as being more preferred or more advantageous than other embodiments or design schemes. Specifically, the use of the word "example" is intended to present concepts in a concrete way. In the embodiments of this application, "of", "corresponding, relevant" and "corresponding" can sometimes be used interchangeably. It should be noted that when the distinction is not emphasized, the meanings to be expressed are consistent.

[0077] To facilitate understanding of the embodiments of the present application, a communication system applicable to the embodiments of the present application will first be described in detail using the communication system shown in FIG1 as an example. As shown in FIG1 , 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.

[0078] The following describes in detail the RAN 100 , CN 100 , and DN 300 involved in FIG1 .

[0079] (1)RAN100

[0080] 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 also include at least one terminal device (such as 120a-120j in Figure 1 ). The terminal device may be wirelessly connected to the radio access network device. Terminal devices and access network devices may be connected to each other via wired or wireless means.

[0081] The access network equipment and terminal equipment can be fixed or mobile. The access network equipment and terminal equipment can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on the water surface; they can also be deployed in the air on aircraft, balloons and artificial satellites. The embodiments of the present application do not limit the application scenarios of the access network equipment and terminal equipment. In addition, the roles of the access network equipment and terminal equipment can be relative. For example, the helicopter or drone 120i in Figure 1 can be configured as a mobile access network equipment. For those terminal devices 120j that access the wireless access network 100 through 120i, 120i is an access network equipment; but for the first access network equipment 10a, 120i is a terminal equipment, that is, the communication between 110a and 120i is through the wireless air interface protocol. Of course, the communication between 110a and 120i can also be carried out through the interface protocol between access network equipment and access network equipment. In this case, relative to 110a, 120i is also an access network equipment. Therefore, access network equipment and terminal equipment can be collectively referred to as communication devices. 110a and 110b in FIG1 can be referred to as communication devices with access network equipment functions, and 120a-120j in FIG1 can be referred to as communication devices with terminal equipment functions.

[0082] (1.1) Terminal equipment

[0083] A terminal device may also be referred to as user equipment (UE), terminal, user device, access terminal, user unit, user station, mobile 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.

[0084] For example, the terminal device in the embodiment of the present application can be a mobile phone, a personal digital assistant (PDA), a laptop computer, a tablet computer, a drone, a computer with wireless transceiver function, a machine type communication (MTC) terminal device, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, an Internet of Things (IoT) terminal device, a wireless terminal device in industrial control, a wireless terminal device in self-driving, a wireless terminal device in remote medical, a wireless terminal device in a smart grid, a wireless terminal device in transportation safety, a wireless terminal device in a smart city, a wireless terminal device in a smart home (such as a game console, a smart TV, a smart speaker, a smart refrigerator, and fitness equipment, etc.), and a vehicle-mounted terminal device.

[0085] (1.2) Access network equipment

[0086] The access network device can be a base station, an evolved NodeB (eNodeB), an access point (AP), a transmission reception point (TRP), a next generation NodeB (gNB), a next generation base station in a 6G mobile communication system, a base station in a future mobile communication system, or an access node in a WiFi system, etc. The access network device can be a macro base station, a micro base station or an indoor station, a relay node or a donor node, or a wireless controller in an open access network (open RAN, O-RAN or ORAN) or a cloud radio access network (cloud radio access network, CRAN) scenario. Optionally, the access network device can also be a server, a wearable device, a vehicle or an on-board device, etc. For example, the access network device in the 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 virtualization functions instantiated on a platform (such as a cloud platform). The access network device in this application may also be a logical node, a logical module or software that can implement all or part of the functions of the access network device.

[0087] In another possible scenario, multiple access network devices collaborate to assist terminal devices 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 centralized unit (CU), a distributed unit (DU), a CU-control plane (CP), a CU-user plane (UP), or a radio unit (RU). The CU and DU can be set separately, or they can 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 a remote radio unit (RRU), an active antenna unit (AAU), or a remote radio head (RRH).

[0088] In different systems, 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, CU may also be called O-CU (Open CU), DU may also be called O-DU, CU-CP may also be called O-CU-CP, CU-UP may also be called O-CU-UP, and RU may also be called O-RU. For the convenience of description, this application uses CU, CU-CP, CU-UP, DU and RU as examples for description. Any unit of CU (or CU-CP, CU-UP), DU and RU in this application can be implemented by a software module, a hardware module, or a combination of a software module and a hardware module.

[0089] In the embodiments of the present application, the functions of the access network device may also be performed by a module (such as a chip) in the access network device, or by a control subsystem that includes the functions of the access network device. The control subsystem that includes the functions of the access network device here may be a control center in the above-mentioned application scenarios such as smart grid, industrial control, smart transportation, and smart city. The functions of the terminal device may also be performed by a module (such as a chip or modem) in the terminal device, or by a device that includes the terminal functions.

[0090] (2)CN200

[0091] CN200 may include multiple core network elements, and radio access network devices may be connected to the core network elements via wireless or wired connections. The core network elements and radio access network devices may be independent physical devices, or the functions of the core network elements and the logical functions of the radio access network devices may be integrated into the same physical device. Alternatively, a single physical device may integrate some of the functions of the core network elements and some of the functions of the radio access network devices.

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

[0093] (3)DN300

[0094] The DN300, also known as a packet data network (PDN), is a network located outside the carrier network. Application servers corresponding to various services can be deployed in the DN300, providing a variety of possible services to terminal devices.

[0095] It is understandable that the solutions in the embodiments of the present application can be applied to a variety of possible communication systems, such as 5G communication systems or future 6G communication systems. The above-mentioned network elements or functions can be 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 is only a schematic diagram, and the RAN of the communication system may also include other access network devices, such as wireless relay devices and wireless backhaul devices.

[0096] In the network architecture illustrated in Figure 1, a user-plane data transmission channel can be established for a terminal device through a control-plane signaling interaction process (e.g., a protocol data unit (PDU) session establishment process). This allows the terminal device to communicate with an application server deployed in the DN through the user-plane data transmission channel. For example, an application server can send a downlink data packet to a terminal device. The downlink data packet's transmission path is: application server → UPF network element → access network device → terminal device. Correspondingly, a terminal device can send an uplink data packet to an application server. The uplink data packet's transmission path is: terminal device → access network device → UPF network element → application server.

[0097] Figure 2A is an example diagram of the protocol layer structure. As shown in Figure 2A, the access network protocol layer structure can be followed between the terminal device and the access network device. 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 may include the L1 layer (i.e., physical layer), the L2 layer (i.e., data link layer), the user datagram protocol (UDP) layer, the internet protocol (IP) layer, the general packet radio service (GPRS) tunneling protocol (GTP)-user plane (GTP-U) layer, etc.; in addition, the UPF network element may also include a PDU session layer that is equivalent to the PDU session layer of the terminal device. The protocol layer structure between the UPF network element and the application server may include the L1 layer, the L2 layer, and other layers, with specific reference to existing protocols; in addition, the application server may also include an application layer that is equivalent to the application layer of the terminal device.

[0098] The access network device can receive GTP-U packets from the UPF network element through the NG interface (also known as the N3 interface or NG-U tunnel). For example, as shown in Figure 2B, the GTP-U packet includes a GTP-U header, an inner IP header, a TCP header, and data. The GTP-U header includes an outer IP header, a UDP header, and a GTP header.

[0099] The following introduces the protocol layer structure between access network equipment and terminal equipment.

[0100] The access network protocol layer structure between the access network device and the terminal device may include a control plane protocol layer structure and a user plane protocol layer structure. FIG2A above illustrates the user plane protocol structure as an example. For example, the control plane protocol layer structure may 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 may include a PDCP layer, an RLC layer, a MAC layer, and a physical layer. In one possible implementation, a service data adaptation protocol (SDAP) layer may also be included above the PDCP layer. Among them, the SDAP layer, the PDCP layer, the RLC layer, the MAC layer, and the physical layer may also be collectively referred to as the access layer. As can be seen from FIG2A , the terminal device also includes a non-access layer, such as a PDU session layer, an application layer, and the like. For a detailed description of each of the above protocol layers, reference may be made to the relevant technical specifications of the 3rd Generation Partnership Project (3GPP).

[0101] When an access network device and a terminal device perform user-plane data transmission, the data needs to pass through the user-plane protocol layers, such as the SDAP layer, PDCP layer, RLC layer, MAC layer, and physical layer. For example, data is transmitted between the access network device and the terminal device by establishing at least one data radio bearer (DRB). Each DRB may correspond to a set of functional entities, such as 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.

[0102] Taking downlink data transmission as an example, Figure 3A illustrates the transmission of downlink data between various layers. As shown in Figure 3A, from the perspective of an access network device, after the SDAP layer entity of the access network device obtains data, it can map the data to the PDCP layer entity of the corresponding DRB based on the data's Quality of Service (QoS) flow indicator (QFI). The PDCP layer entity can then transmit the data to at least one RLC layer entity corresponding to the PDCP layer entity. The at least one RLC layer entity then transmits the data to the corresponding MAC layer entity. The MAC layer entity then generates a transport block, which is then wirelessly transmitted via the corresponding physical layer entity to the terminal device.

[0103] Downlink data can be encapsulated in various layers of the access network device. Data received by a layer from its upper layer is considered a service data unit (SDU) of that layer. After layer encapsulation, it becomes a PDU and is then passed to the next layer. For example, as shown in Figure 3B, the data received by the PDCP layer entity from the SDAP layer can be called a PDCP SDU. After the PDCP layer entity encapsulates the PDCP SDU (for example, by adding a PDCP layer header), it obtains a PDCP PDU and sends it to the RLC layer. The PDCP PDU received by the RLC layer entity from the PDCP layer can be called an RLC SDU. After the RLC layer entity encapsulates the RLC SDU (for example, by adding an RLC layer header), it obtains an RLC PDU and sends it 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, which is also called a transport block, and send the transport block to the physical layer. After receiving the transport block, the physical layer can add verification information, such as a 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.

[0104] When the access network device and the terminal device perform control plane signaling, the signaling needs to pass through the control plane protocol layer, such as the RRC layer, PDCP layer, RLC layer, MAC layer, and physical layer. For example, the access network device and the terminal device establish at least one signaling radio bearer (SRB) to transmit signaling. SRBs and DRBs can be collectively referred to as radio bearers (RBs).

[0105] Take the example of an access network device sending RRC signaling to a terminal device, where RRC signaling can also be referred to as an RRC message. Figure 3A illustrates a schematic diagram of the transmission of RRC messages between layers. As shown in Figure 3A, from the perspective of the access network device, after the RRC layer entity of the access network device generates an RRC message, it can deliver the RRC message 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, which is then transmitted by at least one RLC layer entity to the corresponding MAC layer entity. The MAC layer entity then generates a transmission block, which is then wirelessly transmitted through the corresponding physical layer entity to send to the terminal device.

[0106] 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 pass it from the physical layer to the upper layer in sequence, and each layer can perform the corresponding decapsulation. In other words, 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.

[0107] The network architecture and business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. A person skilled in the art will appreciate that, with the evolution of the network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are equally applicable to similar technical problems.

[0108] In a semantic communication framework based on joint source and channel coding (JSCC), the following scheduling methods can be used:

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

[0110] Step 2: A trade-off between data importance, redundancy, and channel transmission capability guides physical layer channel coding and adaptive transmission. For example, data with a higher entropy estimate is allocated more bandwidth and a lower bit rate during transmission.

[0111] Specifically, at the transmitting end, the source information, such as the original image x, is extracted based on the source category in combination with semantic information coding technology. The semantic information (vector y) and the transmission environment status information are input into the source-channel joint coding module. Based on the trained deep learning model, the above data information is jointly encoded with the source channel and sent to the physical channel for bit data transmission.

[0112] A corresponding receiver model is constructed at the receiving end. For example, the receiver model may include a source-channel joint decoder and a semantic decoder. First, the access end can decode the received bit data information based on the trained source-channel joint 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 is correctly transmitted. Otherwise, the key feature information is used to repair it, or the retransmission of all or part of the source information is triggered. When all the segmented semantic information is decoded, the overall semantic information is restored according to the segmentation method.

[0113] Currently, joint source-channel coding usually requires the transmitter to be able to perform source coding and channel coding simultaneously. However, in layered wireless communication systems, the source and channel belong to different network entities. The source is usually located in the application layer (such as the server), while the channel is located in the physical layer (such as the base station). How to apply joint source-channel coding in current layered wireless communication systems needs to be urgently solved.

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

[0115] In the embodiments of this application, unless otherwise specified, "terminal device" may refer to the terminal device itself or a component of the terminal device, such as a chip or chip system; "access network device" may refer to the access network device itself or a component of the access network device, such as a chip or chip system; and "core network device" may refer to the core network device itself or a component of the core network device, such as a chip or chip system.

[0116] In this application, after a terminal device accesses a wireless network through an access network device, it can subscribe to one or more services. The one or more services may include semantic fault-tolerant services and, optionally, non-semantic fault-tolerant services.

[0117] The following describes the embodiments of the present application in detail with reference to the examples. The following describes the solutions of the present application using uplink scheduling and downlink scheduling as examples. The difference between uplink scheduling and downlink scheduling is that in uplink scheduling, the terminal device indicates the entropy estimate value to the access network device, while in downlink scheduling, the core network device indicates the entropy estimate value to the access network device. The specific process is detailed in Examples 1 and 2 below.

[0118] It should be understood that the first embodiment and the second embodiment can be implemented separately or combined as a solution, which is not specifically limited here.

[0119] It should be noted that the business data involved in Example 1 is business data from the terminal device, or it can also be understood as business data generated by the terminal device (for example, it can be the application layer of the terminal device). The business data involved in Example 1 can also be called uplink business data.

[0120] The service data involved in the second embodiment is service data from the core network device, or can also be understood as service data generated by the core network device (for example, the application layer of the core network device). The service data involved in the second embodiment can also be called downlink service data.

[0121] Example 1: Taking uplink scheduling as an example, FIG4 is a flow chart of a communication method provided in an embodiment of the present application. As shown in FIG4 , the method includes:

[0122] S401: The terminal device sends an entropy estimation value of service data to the access network device. Correspondingly, the access network device receives the entropy estimation value of the service data from the terminal device.

[0123] The entropy estimate is used to characterize the distribution of the bit sequence of the service data within the service data. Alternatively, it can be understood that the entropy estimate is used to measure the amount of information in the service data. A higher entropy estimate indicates more information in the service data, while a lower entropy estimate indicates less information in the service data.

[0124] In an exemplary description, the service data may include one or more bit sequences, and one bit sequence may correspond to one entropy estimation value.

[0125] 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.

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

[0127] S402: The access network device sends scheduling information, and the terminal device receives the scheduling information accordingly.

[0128] The scheduling information is used to configure resources for transmitting the above-mentioned business data, and the scheduling information is related to the entropy estimation value.

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

[0130] The following describes the input and output information of the uplink scheduler.

[0131] Input information about the uplink scheduler:

[0132] 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.

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

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

[0135] Output information about the upstream scheduler:

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

[0137] The cell beam set may include a transceiver channel and simulated beams on the transceiver channel.

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

[0139] Exemplarily, the uplink scheduler may be as shown in FIG5 .

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

[0141] As a possible approach, the scheduling information may be determined by a 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 called a MAC scheduler.

[0142] If the access network device is a CU-DU separated architecture, in this method, the terminal network device can send the entropy estimation value information to the DU, and the DU determines the scheduling information based on the entropy estimation value and sends it to the terminal device.

[0143] The following example illustrates the relationship between scheduling information and entropy estimation.

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

[0145] Assume that the scheduling information includes the bit rate. The bit rate can be inversely proportional to the entropy estimate. The higher the entropy estimate, the lower the bit rate the access network device allocates to the service data. The lower the entropy estimate, the higher the bit rate the access network device allocates to the service data. This approach allows for assigning a lower bit rate to service data with high information volume, thereby ensuring data transmission and improving transmission performance. It also allows for assigning a higher bit rate to service data with low information volume, thereby improving resource utilization and facilitating energy conservation for both terminal devices and access network equipment.

[0146] In the embodiments of the present application, the terminal device transmits the entropy estimate used for source coding to the access network device, allowing the access network device to perform scheduling based on the entropy estimate. This approach enables joint source-channel coding within an architecture where source-channel coding is separated. Furthermore, the access network device considers the entropy estimate when performing data scheduling, significantly improving performance.

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

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

[0149] Optionally, the access network device and the core network device can complete the establishment of a PDU session, where the PDU session is used for semantic fault-tolerant services. In this manner, if the service data is associated with the semantic fault-tolerant service, the access network device can send the service data to the core network device via the PDU session.

[0150] This approach avoids sending both semantically tolerant and non-semantically tolerant services within the same PDU session, DRB, and cell group configuration by configuring separate PDU sessions, DRBs, and cell groups for semantically tolerant services. Because these two types of services have different transmission quality requirements, such as different requirements for transmission fault tolerance, this approach can further improve communication performance.

[0151] As a possible implementation, if the service data is associated with a semantic fault-tolerant service, the terminal device may further indicate to the access network device that the service data is associated with the semantic fault-tolerant service. The following describes three ways in which the terminal device indicates that the service data is associated with the semantic fault-tolerant service.

[0152] In mode A, the terminal device may indicate the service data associated with the semantic fault-tolerant service through a second SR, wherein the second SR is used to request resources for transmitting the input information.

[0153] In method B, the terminal device can indicate the above-mentioned service data-associated semantic fault-tolerant service through BSR.

[0154] The BSR may implicitly indicate that the service data is associated with a semantic fault-tolerant service. For example, the BSR may indicate that the LCG corresponding to the cache state is an LCG configured for the semantic fault-tolerant service. For example, the LCG identifier carried by the BSR is the identifier of the LCG configured in the first message. This method can implicitly indicate that the service data is associated with the semantic fault-tolerant service by associating the LCG with the semantic fault-tolerant service.

[0155] Alternatively, the BSR may also display and indicate that the above-mentioned service data is associated with a semantic fault-tolerant service. For example, the BSR indicates whether the service data is associated with a semantic fault-tolerant service through the value status of a field / indication domain of its corresponding MAC subheader. For example, the MAC subheader of the BSR carries field 1. The first value status of the field 1 indicates that the service data is associated with a semantic fault-tolerant service. The second value status of the field 1 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). For another example, the BSR indicates that the above-mentioned service data is associated with a semantic fault-tolerant service by carrying a special field / indication domain in its corresponding MAC subheader. For example, if the MAC subheader of the BSR carries a special field / indication domain, 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 service data associated with a semantic fault-tolerant service, 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).

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

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

[0158] In addition, the terminal device can also indicate the above-mentioned service data association semantic fault-tolerant service in other ways, which will not be explained here one by one.

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

[0160] Optionally, if the service data is associated with a semantic fault-tolerant service, the scheduling information may indicate that the configured resources are used for the semantic fault-tolerant service.

[0161] The above describes a method for determining scheduling information based on entropy estimation. The following describes a method for a terminal device to send service data after receiving the scheduling information.

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

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

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

[0165] The above method can prevent the data of semantic error-tolerant services and the data of non-semantic error-tolerant services from being filled into the same data block.

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

[0167] In one possible implementation, the access network device may enable the terminal device to report the entropy estimate. For example, the access network device may send configuration information to the terminal device, where the configuration information is used to enable reporting of the entropy estimate. For example, the configuration information may enable reporting of the entropy estimate of data for a semantic fault-tolerant service.

[0168] “Enabling reporting of entropy estimation value” can also be described as “turning on / activating the function of reporting entropy estimation value” or “activating the characteristic of reporting entropy estimation value”, etc., and this application does not make specific limitations.

[0169] In an embodiment of the present application, the entropy estimate value used for source coding is sent to the access network device through the terminal device, so that the access network device can perform scheduling based on the entropy estimate value. In this way, source-channel joint coding can be achieved under an architecture with separated source-channel coding. In addition, the access network device considers the entropy estimate value when performing data scheduling, thereby achieving a significant performance improvement. For example, a larger bandwidth and a lower bit rate can be allocated for a larger amount of information (i.e., a larger entropy estimate value), and a smaller bandwidth and a higher bit rate can be allocated for a smaller amount of information (i.e., a smaller entropy estimate value), thereby achieving variable rate transmission.

[0170] The above content introduces the solution of the present application by taking uplink scheduling as an example. The following introduces the solution of the present application by taking downlink scheduling as an example.

[0171] Example 2: FIG6 is a flow chart of a communication method provided in an embodiment of the present application. As shown in FIG6, the method includes:

[0172] S601: A core network device sends information about an entropy estimation value to an access network device. Correspondingly, the access network device receives the information about the entropy estimation value.

[0173] The entropy estimation value is used to characterize the distribution of the bit sequence of the service data in the service data. For details of the entropy estimation value, please refer to the description of the entropy estimation value in the first embodiment.

[0174] In an exemplary description, 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 may also be described as a feature vector, a vector to be transmitted, a sequence to be transmitted, and the like.

[0175] In a possible implementation, 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.

[0176] In another possible implementation, the information about the entropy estimation value may include an entropy estimation model and service data from a core network device. That is, the core network device may send the entropy estimation model and service data to the access network device. Accordingly, the access network device receives the entropy estimation model and service data from the core network device. In this implementation, the access network device may determine the entropy estimation value based on the service data and the entropy estimation model from the core network device. It should be noted that this application does not limit the order in which the entropy estimation model and service data are sent.

[0177] 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.

[0178] The scheduling information is used to configure resources for transmitting the above-mentioned business data, and the scheduling information is related to the entropy estimation value.

[0179] Exemplarily, the access network device may use the entropy estimate as input information for a downlink scheduler, and the scheduling information is output information of the downlink scheduler. The downlink scheduler is used to allocate resources for downlink transmission. In the present application, the downlink scheduler may allocate resources for transmitting the above-mentioned service data.

[0180] The following describes the input and output information of the downlink scheduler.

[0181] Input information about the downlink scheduler:

[0182] 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.

[0183] 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 (Bandwidth part, BWP) configuration, the synchronization status of the terminal device, the number of receiving antennas and the number of transmitting antennas of the access network device, or the number of receiving antennas and the number of transmitting antennas of the terminal device.

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

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

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

[0187] Output information about the downlink scheduler:

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

[0189] The cell beam set may include a transceiver channel and simulated beams on the transceiver channel.

[0190] 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. 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 Example 1. For details, please refer to the relevant description in Example 1 and will not be repeated here.

[0191] Illustratively, the downlink scheduler may be as shown in FIG7 .

[0192] As a possible approach, the scheduling information may be determined by a MAC layer entity of the access network device, that is, a downlink scheduler may be located in the MAC layer entity of the access network device, and the downlink scheduler may also be called a MAC scheduler.

[0193] If the access network device is a CU-DU separated architecture, in this method, the core network device can send the entropy estimation value information to the CU, the CU sends the entropy estimation value to the DU through the FI interface, and the DU determines the scheduling information based on the entropy estimation value and sends it to the terminal device.

[0194] The following example illustrates the relationship between scheduling information and entropy estimation.

[0195] For example, assuming that the scheduling information includes PDSCH frequency domain resource allocation information. The relationship between the bandwidth (or number of RBs) of the PDSCH frequency domain resources and the entropy estimation value is similar to the relationship between the bandwidth (or number of RBs) of the PUSCH frequency domain resources and the entropy estimation value in Example 1. For details, please refer to the relevant description in Example 1 and will not be described here.

[0196] Assuming that the scheduling information includes the bit rate, the relationship between the bit rate and the entropy estimation value is similar to that in the first embodiment, and the details can be referred to the relevant description in the first embodiment, which will not be described here.

[0197] In the embodiments of the present application, the core network device transmits the entropy estimate used for source coding to the access network device, allowing the access network device to perform scheduling based on the entropy estimate. This approach enables joint source-channel coding in an architecture with separate source-channel coding. Furthermore, the access network device considers the entropy estimate when performing data scheduling, significantly improving performance.

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

[0199] In a possible implementation, the core network device may further send the service data to the access network device. The access network device may send the service data to the terminal device according to the scheduling information.

[0200] Optionally, before S601, the access network device and the core network device may complete the establishment of a PDU session, where the PDU session is used for semantic fault-tolerant services. In this manner, if the service data is associated with the semantic fault-tolerant service, the core network device may send the service data to the access network device via the PDU session.

[0201] Optionally, the access network device may send a second message to the terminal device, where the second message is used to configure the DRB and cell group configuration for the semantic fault-tolerant service. Exemplarily, the cell group configuration may be an LCG. In this manner, if the service data is associated with the semantic fault-tolerant service, the access network device may send the service data to the terminal device using the DRB and cell group configuration.

[0202] In one possible implementation, the PDU session, DRB and cell group configuration of the semantic fault-tolerant service in Example 2 may be the same as the PDU session, DRB and cell group configuration of the semantic fault-tolerant service in Example 1. That is, the PDU session established between the core network device and the access network device may be used to transmit the service data in Example 1, and may also be used to transmit the service data in Example 2. The DRB and cell group configuration configured by the access network device may be used to transmit the service data in Example 1, and may also be used to transmit the service data in Example 2.

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

[0204] In the embodiment of the present application, the entropy estimate value used for source coding is sent to the access network device through the core network device, so that the access network device can be scheduled according to the entropy estimate value. In this way, source-channel joint coding can be achieved under the architecture of source-channel coding separation. In addition, the access network device considers the entropy estimate value when performing data scheduling, thereby achieving a significant performance improvement. For example, a larger bandwidth and a lower bit rate can be allocated for a larger amount of information (that is, a larger entropy estimate value), and a smaller bandwidth and a higher bit rate can be allocated for a smaller amount of information (that is, a smaller entropy estimate value), thereby achieving variable rate transmission.

[0205] Based on the same inventive concept as the method embodiment, an embodiment of the present application provides a communication device, the structure of which may be as shown in FIG8 , including a communication unit 801 and a processing unit 802 .

[0206] In one embodiment, a communication device can be specifically used to implement the method performed by the terminal device in the embodiment of FIG. 4 . The device can be the terminal device itself, or a chip, chipset, or a portion of a chip in the terminal device that performs the functions of the related method. The processing unit 802 is configured to send an entropy estimate of service data to the access network device via the communication unit 801 . The entropy estimate is used to characterize the distribution of bit sequences of the service data in the service data; and to receive scheduling information from the access network device via the communication unit 801 . The scheduling information is used to configure resources for transmitting the service data, and the scheduling information is related to the entropy estimate.

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

[0208] 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.

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

[0210] 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 a semantic fault-tolerant service, and the service data is associated with the semantic fault-tolerant service.

[0211] 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 estimation value.

[0212] In one embodiment, a communication device can be specifically used to implement the method performed by the access network device in the embodiment of FIG. 4 . The device can be the access network device itself, or a chip, chipset, or a portion of a chip in the access network device that is used to perform the functions of the related method. The processing unit 802 is configured to receive an entropy estimate from a terminal device via the communication unit 801 , where the entropy estimate is used to characterize the distribution of a bit sequence of service data in the service data; and to send scheduling information to the terminal device via the communication unit 801 , where the scheduling information is used to configure resources for transmitting service data, and the scheduling information is determined based on the entropy estimate.

[0213] 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-tolerant service.

[0214] 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-tolerant service.

[0215] Optionally, the processing unit 802 is further used 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-tolerant service.

[0216] 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.

[0217] In one embodiment, a communication device can be specifically used to implement the method performed by the access network device in the embodiment of FIG. 6 . The device can be the access network device itself, or a chip, chipset, or portion of a chip in the access network device that performs the functions of the related method. The processing unit 802 is configured to receive information about an entropy estimate from a core network device, where the entropy estimate is used to characterize the distribution of a bit sequence of service data in the service data; and to send scheduling information to a terminal device via the communication unit 801, where the scheduling information is used to configure resources for transmitting service data, and the scheduling information is determined based on the entropy estimate.

[0218] 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 a data radio bearer and a logical channel group for a semantic fault-tolerant service, and the service data is associated with the semantic fault-tolerant service.

[0219] In one embodiment, a communication device can be specifically used to implement the method performed by the core network device in the embodiment of FIG. 6 . The device can be the core network device itself, or a chip, chipset, or portion of a chip within the core network device that performs the functions of the related method. The processing unit 802 is configured to determine information about an entropy estimate, where the entropy estimate is used to characterize the distribution of a bit sequence of service data within the service data; and the communication unit 801 is configured to transmit information.

[0220] The division of modules in the embodiments of the present application is schematic and is only a logical function division. In actual implementation, there may be other division methods. In addition, the functional modules in the various embodiments of the present application can be integrated into a processor, or can exist physically separately, or two or more modules can be integrated into one module. The above-mentioned integrated modules can be implemented in the form of hardware or in the form of software functional modules. It is understood that the functions or implementations of the various modules in the embodiments of the present application can be further referred to the relevant description of the method embodiment.

[0221] In one possible embodiment, a communication device may be as shown in FIG9 . The device may be a communication device or a chip within the communication device, wherein the communication device may be a terminal device or a network device in the above embodiments. The device includes a processor 901 and a communication interface 902, and may also include a memory 903. 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 be integrated.

[0222] The processor 901 may be a CPU, a digital processing unit, or the like. The communication interface 902 may be a transceiver, an interface circuit such as a transceiver circuit, or a transceiver chip, or the like. The apparatus further includes a memory 903 for storing programs 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), or a volatile memory (volatile memory), such as a random-access memory (RAM). The memory 903 is any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto.

[0223] The processor 901 is used to execute the program code stored in the memory 903, specifically to execute the actions of the processing unit 802, which will not be described in detail in this application. The communication interface 902 is specifically used to execute the actions of the communication unit 801, which will not be described in detail in this application.

[0224] The specific connection medium between the communication interface 902, processor 901, and memory 903 is not limited in the embodiments of the present application. In Figure 9, the embodiment of the present application shows that the memory 903, processor 901, and communication interface 902 are connected via bus 904. The bus is represented by a bold line in Figure 9. The connection method between other components is only for schematic illustration and is not limiting. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, only one bold line is used in Figure 9, but this does not mean that there is only one bus or one type of bus.

[0225] An embodiment of the present invention further provides a computer-readable storage medium for storing computer software instructions required to be executed by the above-mentioned processor, which includes a program required to be executed by the above-mentioned processor.

[0226] An embodiment of the present application also provides a communication system, including a communication device for implementing the terminal device function in the embodiment of Figure 4 and a communication device for implementing the access network device function in the embodiment of Figure 4.

[0227] An embodiment of the present application also provides a communication system, including a communication device for implementing the core network device function in the embodiment of Figure 6 and a communication device for implementing the access network device function in the embodiment of Figure 6.

[0228] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0229] 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 flow and / or box in the flow chart and / or block diagram, as well as the combination of the flow chart and / or box in the flow chart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more flow charts and / or one or more boxes in the block diagram.

[0230] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0231] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0232] Obviously, those skilled in the art may make various changes and modifications 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 equivalents, the present application is intended to include these modifications and variations.

Claims

1. A communication method, characterized in that: The method is applied to a terminal device, and the method comprises: Sending an entropy estimation value of the service data to the access network device, where the entropy estimation value is used to characterize the distribution of a bit sequence of the service data in the service data; Receive 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 estimation value.

2. The method according to claim 1, characterized in that Before sending the entropy estimation value of the service data, the method further includes: A scheduling request is sent, 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 comprises: A buffer status report is sent, wherein the buffer status report indicates that the service data is associated with a semantically fault-tolerant service.

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

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

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

7. The method according to any one of claims 1 to 6, characterized in that: The method further comprises: A first message is received, where the first message is used to configure a data radio bearer and a logical channel group of a 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 to 7, characterized in that: The method further comprises: Configuration information is received, where the configuration information is used to enable reporting of the entropy estimate.

9. A communication method, characterized in that: The method is applied to an access network device, and the method comprises: Receiving an entropy estimation value from a terminal device, wherein the entropy estimation value is used to characterize distribution of a 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 based on the entropy estimation value.

10. The method according to claim 9, characterized in that Before receiving the entropy estimation value of the business data, the method further includes: A scheduling request is received, where the scheduling request indicates that the service data is associated with a semantically fault-tolerant service.

11. The method according to claim 9 or 10, characterized in that The method further comprises: A buffer status report is received, wherein the buffer status report indicates that the service data is associated with a semantically fault-tolerant service.

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

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

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

15. The method according to any one of claims 9 to 14, characterized in that: The method further comprises: Sending configuration information, where the configuration information is used to enable reporting of the entropy estimate.

16. A communication method, characterized in that: The method is applied to an access network device, and the method comprises: Receiving information about an entropy estimate value from a core network device, where the entropy estimate value is used to characterize distribution of a 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 based on the entropy estimation value.

17. The method according to claim 16, characterized in that The information of the entropy estimation value is the entropy estimation value; Alternatively, the information of the entropy estimation value includes an entropy estimation value model and business data.

18. The method according to claim 16 or 17, characterized in that The scheduling information indicates that the configured resources are used for semantic fault-tolerant services.

19. The method according to any one of claims 16 to 18, characterized in that: The method further comprises: Send a first message, the first message is used to configure a data radio bearer and a logical channel group for a semantic fault-tolerant service, the service data The semantic fault-tolerant service is associated.

20. A communication method, characterized in that: The method is applied to a core network device, and the method includes: Determine information of an entropy estimate value, wherein the entropy estimate value is used to characterize distribution of a bit sequence of the service data in the service data; The information is sent.

21. The method of claim 20, wherein: The information is the entropy estimate; Alternatively, the information includes an entropy estimation value model and business data.

22. A communication device, characterized in that: Comprising a unit or module for executing the method as claimed in any one of claims 1 to 8, or comprising a unit or module for executing the method as claimed in any one of claims 9 to 15, or comprising a unit or module for executing the method as claimed in any one of claims 16 to 19, or comprising a unit or module for executing the method as claimed in claim 20 or 21.

23. A communication device, characterized in that: The invention comprises a processor and a memory, wherein the memory is used to store program instructions, and when the processor executes the program instructions, the method as claimed in any one of claims 1 to 8 is executed, or the method as claimed in any one of claims 9 to 15 is executed, or the method as claimed in any one of claims 16 to 19 is executed, or the method as claimed in claim 20 or 21 is executed.

24. A computer-readable storage medium, characterized in that: The computer storage medium stores computer-readable instructions, and when the computer-readable instructions are executed on the communication device, the method as described in any one of claims 1 to 8 is executed, or the method as described in any one of claims 9 to 15 is executed, or the method as described in any one of claims 16 to 19 is executed, or the method as described in claim 20 or 21 is 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 of any one of claims 1 to 8, or the method of any one of claims 9 to 15, or the method of any one of claims 16 to 19, or the method of claim 20 or 21.

Images