Method, apparatus and system for joint uplink encoding and decoding

Abstract

For joint uplink encoding and decoding, input bits including data bits and bits associated with control information are encoded to generate encoded bits, and the encoded bits can be decoded to recover the data bits and the bits associated with the control information. The encoding includes jointly encoding the data bits and the bits associated with the control information according to a first code, the first code being different from a second code, the second encoded bits being generated from the control information according to the second code. In some embodiments, both the encoded bits and the second encoded bits are transmitted or otherwise output, and the control information can be decoded from either or both of the encoded bits and the second encoded bits.

Description

[0001] Cross-reference to related applications

[0002] This application relates to and claims priority to U.S. Provisional Patent Application Serial No. 63 / 600,164, filed November 17, 2023, entitled “METHODS, APPARATUS, AND SYSTEMS FOR JOINT UPLINK ENCODING AND DECODING,” the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to codecs for wireless communication, and more particularly to the joint codecs of control information and data. Background Technology

[0004] Hybrid service codecs consider multiple services (at least two services) with different service types. The first service type (e.g., URLLC) can be protected by a smaller codebase (smaller codebase length), while the second service type (e.g., eMBB), due to its larger payload, can be protected by a larger codebase. An example of hybrid service codecs is to embed some or all of the information bits from the smaller codebase into the payload of the larger codebase and encode them together in the larger codebase. Decoding the smaller codebase can enhance the decoding of the larger codebase, and if the smaller codebase cannot be decoded independently, decoding the larger codebase can also improve the reliability of the smaller codebase, thereby reducing the likelihood of smaller codebase retransmission.

[0005] This hybrid service codec can enhance the decoding of services. Further improvements in the reliability of control information may be needed. Summary of the Invention

[0006] Some aspects of this disclosure add a process between decoding failure and retransmission request.

[0007] Some aspects of this disclosure relate to channel coding / decoding designs that simultaneously support self-decoding capabilities and enhanced joint decoding capabilities.

[0008] Some aspects of this disclosure relate to a three-stage decoding attempt transmission method. This method may include a process called joint decoding, which is interposed between decoding failures and retransmission requests.

[0009] In some embodiments, the hybrid service encoding and decoding process can also be applied to the joint encoding of control and data information. However, in many scenarios, control and data information can be encoded using different encoding and decoding types. For example, control information can be encoded using polar codes and typically decoded using a hard-decision decoder, while data information can be encoded using LDPC codes and can be decoded using a soft-in, soft-out decoder. In some examples of this disclosure, a method for jointly encoding control and data to enhance the reliability of control information is described. Furthermore, the control channel can also be encoded and transmitted separately to maintain self-decoding capability. One application example of joint encoding of control and data is its application to UCI and UL data (UL-SCH) multiplexing.

[0010] According to one aspect of this disclosure, a method includes: encoding input bits to generate encoded bits, and outputting the encoded bits. The input bits include data bits and bits associated with control information, and the encoding includes jointly encoding the data bits and the bits associated with the control information. Jointly encoding the data bits and the bits associated with the control information includes jointly encoding the data bits and the bits associated with the control information according to a first code, which is different from a second code, wherein the second encoded bits are generated from the control information according to the second code.

[0011] Another method disclosed herein includes: receiving coded bits generated by jointly encoding input bits, wherein the input bits include data bits and bits associated with control information; and outputting recovered data bits and bits associated with the control information decoded from the received coded bits. In this example, the input bits have been jointly encoded according to a first code, which is different from a second code, and the second coded bits are generated from the control information according to the second code.

[0012] An apparatus according to one embodiment includes: an encoder for encoding input bits to generate coded bits; and an interface coupled to the encoder for outputting the coded bits. The input bits include data bits and bits associated with control information, and the encoding includes jointly encoding the data bits and the bits associated with the control information. Jointly encoding the data bits and the bits associated with the control information includes jointly encoding the data bits and the bits associated with the control information according to a first code, the first code being different from a second code, wherein the second coded bits are generated from the control information according to the second code.

[0013] According to another aspect of this disclosure, an apparatus includes an interface for receiving coded bits generated by jointly encoding input bits, wherein the input bits include data bits and bits associated with control information, the input bits being jointly encoded according to a first code, which is different from a second code, and second coded bits being generated from the control information according to the second code. Such an apparatus may further include a decoder coupled to the interface for decoding recovered data bits and the bits associated with the control information from the received coded bits.

[0014] In other device embodiments, a device may include a processor for causing the device to perform any of the methods disclosed herein.

[0015] An apparatus may include a processor and a nontransitory computer-readable storage medium coupled to the processor and storing a program for execution by the processor.

[0016] Storage media need not necessarily be, or only need to be, implemented in or in conjunction with such a device. A computer program product may, for example, be or include a non-transitory computer-readable medium storing a program for execution by a processor.

[0017] A program stored in a computer-readable storage medium may include instructions for or for causing a processor to perform, implement, support or enable any of the methods disclosed herein.

[0018] A system is also disclosed, which may include: a first communication device for: encoding input bits to generate encoded bits and transmitting the encoded bits; and a second communication device for receiving and decoding the encoded bits. The input bits include data bits and bits associated with control information, and the input bits are encoded by jointly encoding the data bits and the bits associated with the control information. Jointly encoding the data bits and the bits associated with the control information includes jointly encoding the data bits and the bits associated with the control information according to a first code, the first code being different from a second code, and the second encoded bits being generated from the control information according to the second code.

[0019] This disclosure covers these and other aspects or embodiments. Attached Figure Description

[0020] To gain a more comprehensive understanding of the embodiments and advantages of this disclosure, the following description is provided by way of example in conjunction with the accompanying drawings:

[0021] Figure 1This is a simplified diagram of a communication system.

[0022] Figure 2 yes Figure 1 A block diagram of an exemplary communication system.

[0023] Figure 3 An example of an exemplary electronic device and a base station is shown.

[0024] Figure 4 The unit or module in the device is shown.

[0025] Figure 5 Self-decoding and joint decoding are shown.

[0026] Figure 6 A robotic arm including video equipment and two joints and communicating with a base station is shown.

[0027] Figure 7 Exemplary code blocks and encoded symbols are shown.

[0028] Figure 8 Another exemplary code block and encoded symbol are shown.

[0029] Figure 9 Another exemplary code block and encoded symbol are shown.

[0030] Figure 10 The sequential coupling of bits between individual payloads is shown.

[0031] Figure 11 This illustrates the many-to-one coupling of bits between individual payloads.

[0032] Figure 12 An exemplary application and the process of joint UCI and UL data transmission are illustrated.

[0033] Figure 13 An example of combining UCI and UL-SCH encoding / decoding is shown.

[0034] Figure 14 An example of embedding the entire UCI-encoded bit into UL data is shown.

[0035] Figure 15 Examples of different portions of encoded bits from UCI are shown.

[0036] Figure 16 An example of high-priority UCI coupling is shown.

[0037] Figure 17 An example of UCI rate matching considering coupled bits is shown.

[0038] Figure 18A decoding example is shown.

[0039] Figure 19 An example of the UCI and UL-SCH resource reuse process is shown.

[0040] Figure 20 An example of resource mapping is shown.

[0041] Figure 21 An exemplary method according to an embodiment is shown.

[0042] Figure 22 An apparatus according to an embodiment is shown. Detailed Implementation

[0043] For illustrative purposes, specific exemplary embodiments are explained in detail below with reference to the accompanying drawings.

[0044] The embodiments described herein illustrate information sufficient to practice the claimed subject matter and explain methods for practicing such subject matter. Those skilled in the art will understand the concepts of the claimed subject matter upon reading the following description with reference to the accompanying drawings, and will recognize that the application of these concepts is not specifically mentioned herein. It should be understood that these concepts and applications are within the scope of this disclosure and the appended claims.

[0045] refer to Figure 1 A simplified schematic diagram of a communication system is provided as an illustrative, not limiting, example. Communication system 100 includes a radio access network 120. Radio access network 120 can be a next-generation (e.g., sixth-generation, 6G, or later) radio access network or a traditional (e.g., 5G, 4G, 3G, or 2G) radio access network. One or more electronic devices (EDs) 110a, 110b, 110c, 110d, 110e, 110f, 110g, 110h, 110i, 110j (generally referred to as 110) can be interconnected or connected to one or more network nodes (170a, 170b, generally referred to as 170) in radio access network 120. Core network 130 can be part of the communication system and can depend on or be independent of the radio access technology used in communication system 100. In addition, the communication system 100 includes a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160.

[0046] Figure 2An example communication system 100 is illustrated. Generally, communication system 100 enables multiple wireless or wired components to transmit data and other content. The purpose of communication system 100 may be to provide content such as voice, data, video, and / or text via broadcast, multicast, unicast, etc. Communication system 100 can operate by sharing resources (such as carrier spectrum bandwidth) among its constituent components. Communication system 100 may include terrestrial communication systems and / or non-terrestrial communication systems. Communication system 100 can provide a wide range of communication services and applications, such as earth monitoring, remote sensing, passive sensing and positioning, navigation and tracking, autonomous delivery, and mobility. Communication system 100 can provide high availability and robustness through the joint operation of terrestrial and non-terrestrial communication systems. For example, integrating a non-terrestrial communication system (or components thereof) into a terrestrial communication system can create a heterogeneous network that can be viewed as comprising multiple layers. Compared to traditional communication networks, heterogeneous networks can achieve better overall performance through efficient multi-link joint operation, more flexible function sharing, and faster physical layer link switching between terrestrial and non-terrestrial networks.

[0047] Terrestrial communication systems and non-terrestrial communication systems can be considered subsystems of a communication system. Figure 2 In the example shown, communication system 100 includes electronic devices (EDs) 110a, 110b, 110c, and 110d (generally referred to as ED110), radio access networks (RANs) 120a and 120b, a non-terrestrial communication network 120c, a core network 130, a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160. RANs 120a and 120b include corresponding base stations (BSs) 170a and 170b, which are typically referred to as terrestrial transmit and receive points (T-TRPs) 170a and 170b. The non-terrestrial communication network 120c includes an access node 172, which is typically referred to as a non-terrestrial transmit and receive point (NT-TRP) 172.

[0048] Alternatively or additionally, any ED 110 can be used to connect, access, or communicate with any T-TRP 170a, 170b, NT-TRP 172, Internet 150, core network 130, PSTN 140, other network 160, or any combination thereof. In some examples, ED 110a can perform uplink and / or downlink transmissions with T-TRP 170a via terrestrial air interface 190a. In some examples, ED 110a, 110b, 110c, and 110d can also communicate directly with each other via one or more sidelink air interfaces 190b. In some examples, ED 110d can perform uplink and / or downlink transmissions with NT-TRP 172 via non-terrestrial air interface 190c.

[0049] Air interfaces 190a and 190b can use similar communication technologies, such as any suitable wireless access technology. For example, communication system 100 can implement one or more channel access methods in air interfaces 190a and 190b, such as code division multiple access (CDMA), space division multiple access (SDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or single-carrier FDMA (SC-FDMA), also known as discrete Fourier transform spread OFDMA (DFT-s-OFDMA). Air interfaces 190a and 190b can utilize other higher-dimensional signal spaces, which may involve combinations of orthogonal and / or non-orthogonal dimensions.

[0050] The non-terrestrial air interface 190c enables communication between the ED 110d and one or more NT-TRP 172s via a wireless link or simply through a link. In some examples, the link is a dedicated connection for unicast transmission, a connection for broadcast transmission, or a connection between a group of ED 110s and one or more NT-TRP 172s for multicast transmission.

[0051] RANs 120a and 120b communicate with the core network 130 to provide various services, such as voice, data, and other services, to EDs 110a, 110b, and 110c. RANs 120a and 120b and / or the core network 130 can communicate directly or indirectly with one or more other RANs (not shown), which may or may not be directly served by the core network 130, and may or may not use the same radio access technology as RANs 120a and / or RAN 120b. The core network 130 can also serve as a gateway access between (i) RANs 120a and 120b and / or EDs 110a, 110b, and 110c, and (ii) other networks (e.g., PSTN 140, Internet 150, and other networks 160). Additionally, some or all of EDs 110a, 110b, and 110c may include the ability to communicate with different wireless networks via different radio links using different radio technologies and / or protocols. ED 110a, 110b, and 110c can communicate with a service provider or exchange (not shown) via a wired communication channel and with the Internet 150, rather than via wireless communication (or via wired communication in addition to wireless communication). PSTN 140 may include a circuit-switched telephone network for providing plain old telephone service (POTS). The Internet 150 may include a network of computers and subnets (intranets) or both, and also includes protocols such as Internet Protocol (IP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP). ED 110a, 110b, and 110c can be multimode devices capable of operating under various wireless access technologies and may include multiple transceivers required to support such operation.

[0052] Figure 3Another example of the ED 110 and base stations 170a, 170b, and / or 170c is shown. The ED 110 is used to connect people, objects, machines, etc. The ED 110 can be widely used in various scenarios, including cellular communication, device-to-device (D2D), vehicle-to-everything (V2X), peer-to-peer (P2P), machine-to-machine (M2M), machine-type communications (MTC), Internet of Things (IoT), virtual reality (VR), augmented reality (AR), mixed reality (MR), metaverse, digital twins, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery, and mobility.

[0053] Each ED 110 represents any suitable end-user equipment for wireless operation and may include (or be referred to as) devices such as: user equipment / device (UE), wireless transmit / receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular phone, station (STA), machine type communication (MTC) device, personal digital assistant (PDA), smartphone, laptop, computer, tablet, wireless sensor, consumer electronics, smartbook, vehicle, automobile, truck, bus, train, or IoT device, wearable device (such as watch, glasses, head-mounted device, etc.), industrial equipment, or means of the above devices or constituting the above devices (e.g., communication module, modem, or chip). Future generations of ED 110 may be referred to using other terms. Base stations 170a and 170b are T-TRPs, referred to below as T-TRP 170. Alternatively... Figure 3As shown, NT-TRP is referred to as NT-TRP 172 below. Each ED 110 connected to T-TRP 170 and / or NT-TRP 172 can be dynamically or semi-statically enabled (i.e., established, activated, or enabled), disabled (i.e., released, deactivated, or disabled), and / or configured in response to one or more of connectivity availability and connectivity necessity.

[0054] ED 110 includes a transmitter 201 and a receiver 203 coupled to one or more antennas 204. Only one antenna 204 is shown in the figure to avoid congestion. One, some, or all of the antennas 204 may also be panels. The transmitter 201 and receiver 203 may be integrated as a transceiver, etc. The transceiver is used to modulate data or other content for transmission through at least one antenna 204 or a network interface controller (NIC). The transceiver is also used to demodulate data or other content received through at least one antenna 204. Each transceiver includes any suitable structure for generating signals for wireless or wired transmission and / or for processing signals received wirelessly or wiredly. Each antenna 204 includes any suitable structure for transmitting and / or receiving wireless or wired signals.

[0055] ED 110 includes at least one memory 208. Memory 208 stores instructions and data used, generated, or collected by ED 110. For example, memory 208 may store software instructions or modules executed by one or more processing units (e.g., processor 210) for implementing some or all of the functions and / or embodiments described herein. Each memory 208 includes any suitable one or more volatile and / or non-volatile storage and retrieval devices. Any suitable type of memory can be used, such as random access memory (RAM), read-only memory (ROM), hard disk, optical disk, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, on-processor cache, etc.

[0056] ED 110 may also include one or more input / output devices (not shown) or interfaces (e.g., Figure 1(Wired interface of Internet 150 in the network). Input / output devices or interfaces support interaction with users or other devices in the network. Each input / output device or interface includes any suitable structure for providing or receiving information from the user and / or for network interface communication. For example, suitable structures include speakers, microphones, keypads, keyboards, displays, touchscreens, etc.

[0057] ED 110 includes a processor 210 for performing operations including: operations related to preparing uplink transmissions to NT-TRP 172 and / or T-TRP 170; operations related to processing downlink transmissions received from NT-TRP 172 and / or T-TRP 170; and operations related to processing sidelink transmissions to and from another ED 110. Processing operations related to preparing uplink transmissions may include operations such as encoding, modulation, transmit beamforming, and generating symbols for transmission. Processing operations related to processing downlink transmissions may include operations such as receive beamforming, demodulation, and decoding of received symbols. According to an embodiment, receiver 203 may receive downlink transmissions (possibly using receive beamforming), and processor 210 may extract signaling from the downlink transmissions (e.g., by detecting and / or decoding signaling). Examples of signaling may be reference signals transmitted by NT-TRP 172 and / or T-TRP 170. In some embodiments, processor 210 performs transmit beamforming and / or receive beamforming based on beam direction indication (e.g., beam angle information (BAI)) received from T-TRP 170. In some embodiments, processor 210 may perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as operations related to detecting synchronization sequences, decoding, and acquiring system information. In some embodiments, for example, processor 210 may perform channel estimation using reference signals received from NT-TRP 172 and / or T-TRP 170.

[0058] Although not shown, processor 210 may be part of transmitter 201 and / or receiver 203. Although not shown, memory 208 may be part of processor 210.

[0059] The processor 210, the processing components of the transmitter 201, and the processing components of the receiver 203 may each be implemented by the same or different one or more processors for executing instructions stored in memory (e.g., memory 208). Alternatively, some or all of the processing components of the processor 210, the transmitter 201, and the receiver 203 may be implemented using hardware accelerators such as a programmable field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a graphics processing unit (GPU), or an artificial intelligence (AI) accelerator.

[0060] In some implementations, the T-TRP 170 may have other names, such as base station, basetransceiver station (BTS), wireless base station, network node, network device, network-side device, transmit / receive node, NodeB, evolved NodeB (eNodeB or eNB), home eNodeB, next-generation NodeB (gNB), transmission point (TP), site controller, access point (AP), wireless router, relay station, ground node, ground network device, ground base station, baseband unit (BBU), remote radio unit (RRU), active antenna unit (AAU), remote radio head (RRH), central unit (CU), distributed unit (DU), positioning node, etc. The T-TRP 170 can be a macro BS, pico BS, relay node, host node, or a combination thereof. T-TRP 170 may refer to the aforementioned equipment or to a component within the aforementioned equipment (e.g., a communication module, modem, or chip).

[0061] In some embodiments, the various parts of T-TRP 170 may be distributed. For example, some modules in T-TRP 170 may be located remotely from the device housing the antenna 256 of T-TRP 170 and may be coupled to the device housing the antenna 256 via a communication link (not shown) sometimes referred to as a fronthaul (such as a common public radio interface (CPRI)). Therefore, in some embodiments, the term "T-TRP 170" may also refer to network-side modules that perform processing operations such as determining the location of ED 110, resource allocation (scheduling), message generation, and encoding / decoding, which are not necessarily part of the device housing the antenna 256 of T-TRP 170. These modules may also be coupled to other T-TRPs. In some embodiments, T-TRP 170 may actually be multiple T-TRPs operating together to serve ED 110 through cooperative multicast and other methods.

[0062] T-TRP 170 includes at least one transmitter 252 and at least one receiver 254 coupled to one or more antennas 256. Only one antenna 256 is shown in the figure to avoid congestion. One, some, or all of the antennas 256 may also be panels. The transmitter 252 and receiver 254 may be integrated as a transceiver. T-TRP 170 also includes a processor 260 for performing operations related to: preparing downlink transmissions to be transmitted to ED 110, processing uplink transmissions received from ED 110, preparing backhaul transmissions to be transmitted to NT-TRP 172, and processing transmissions received from NT-TRP 172 via backhaul. Processing operations related to preparing downlink or backhaul transmissions may include operations such as encoding, modulation, precoding (e.g., multiple-input multiple-output (MIMO) precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing transmissions received in the uplink or via backhaul may include operations such as receive beamforming, demodulating received symbols, and decoding received symbols. Processor 260 can also perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as generating the contents of a synchronization signal block (SSB), generating system information, etc. In some embodiments, processor 260 also generates beam direction indications, such as BAI, that can be scheduled for transmission by scheduler 253. Processor 260 performs other network-side processing operations described herein, such as determining the location of ED 110, determining the location for deploying NT-TRP 172, etc. In some embodiments, processor 260 can generate signaling, such as configuring one or more parameters of ED 110 and / or one or more parameters of NT-TRP 172. Any signaling generated by processor 260 is transmitted by transmitter 252. It should be noted that the term "signaling" used herein can also be referred to as control signaling. Signaling can be transmitted in a physical layer control channel (e.g., a physical downlink control channel (PDCCH)), in which case the signaling can be referred to as dynamic signaling. Signaling transmitted in the downlink physical layer control channel is called downlink control information (DCI). Signaling transmitted in the uplink physical layer control channel is called uplink control information (UCI). Signaling transmitted in the sidelink physical layer control channel is called sidelink control information (SCI).Signaling can be included in higher-layer (e.g., above the physical layer) packets transmitted in physical layer data channels (e.g., physical downlink shared channel, PDSCH). In this case, the signaling can be called higher-layer signaling, static signaling, or semi-static signaling. Higher-layer signaling can also refer to radio resource control (RRC) protocol signaling or media access control-control element (MAC-CE) signaling.

[0063] Scheduler 253 may be coupled to processor 260. Scheduler 253 may be included within T-TRP 170 or may operate separately from T-TRP 170. Scheduler 253 may schedule uplink, downlink, lateral link, and / or backlink transmissions, including issuing scheduling authorizations and / or configuring schedule-free (e.g., “configuration authorization”) resources. T-TRP 170 also includes memory 258 for storing information and data. Memory 258 stores instructions and data used, generated, or collected by T-TRP 170. For example, memory 258 may store software instructions or modules executed by processor 260 for implementing some or all of the functions and / or embodiments described herein.

[0064] Although not shown, processor 260 may be part of transmitter 252 and / or receiver 254. Furthermore, although not shown, processor 260 may implement scheduler 253. Although not shown, memory 258 may be part of processor 260.

[0065] The processing components of processor 260, scheduler 253, transmitter 252, and receiver 254 may each be implemented by the same or different one or more processors for executing instructions stored in memory (e.g., memory 258). Alternatively, some or all of the processing components of processor 260, scheduler 253, transmitter 252, and receiver 254 may be implemented using dedicated circuitry such as a programmable FPGA, hardware accelerator (e.g., GPU or AI accelerator), or ASIC.

[0066] Although the NT-TRP 172 is shown as an example of a drone only, it can be implemented in any suitable non-terrestrial form, such as satellites and high-altitude platforms including international mobile communication base stations and unmanned aerial vehicles. Furthermore, in some implementations, the NT-TRP 172 may have other names, such as a non-terrestrial node, a non-terrestrial network device, or a non-terrestrial base station. The NT-TRP 172 includes a transmitter 272 and a receiver 274 coupled to one or more antennas 280. Only one antenna 280 is shown in the figure to avoid congestion. One, some, or all of the antennas may also be panels. The transmitter 272 and receiver 274 may be integrated as a transceiver. The NT-TRP 172 also includes a processor 276 for performing operations related to: preparing downlink transmissions to be sent to ED 110, processing uplink transmissions received from ED 110, preparing backhaul transmissions to be sent to T-TRP 170, and processing transmissions received from T-TRP 170 via backhaul. Processing operations related to preparing to transmit downlink or backhaul transmissions may include operations such as encoding, modulation, precoding (e.g., MIMO precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing transmissions received in the uplink or via backhaul may include operations such as receive beamforming, demodulating received symbols, and decoding received symbols. In some embodiments, processor 276 performs transmit beamforming and / or receive beamforming based on beam direction information (e.g., BAI) received from T-TRP 170. In some embodiments, processor 276 may generate signaling to configure one or more parameters of ED 110. In some embodiments, NT-TRP 172 implements physical layer processing but does not implement higher-level functions such as medium access control (MAC) or radio link control (RLC) layer functions. Since this is only an example, in general, NT-TRP 172 may implement higher-level functions in addition to physical layer processing.

[0067] The NT-TRP 172 also includes a memory 278 for storing information and data. Although not shown, a processor 276 may form part of the transmitter 272 and / or the receiver 274. Although not shown, the memory 278 may form part of the processor 276.

[0068] The processing components of processor 276, transmitter 272, and receiver 274 can each be implemented by the same or different one or more processors for executing instructions stored in memory (e.g., memory 278). Alternatively, some or all of the processing components of processor 276, transmitter 272, and receiver 274 can be implemented using dedicated circuitry such as a programmable FPGA, hardware accelerator (e.g., GPU or AI accelerator), or ASIC. In some embodiments, NT-TRP 172 can actually be multiple NT-TRPs operating together to serve ED 110 via cooperative multicast or similar methods.

[0069] T-TRP 170, NT-TRP 172 and / or ED 110 may include other components, but these components have been omitted for clarity.

[0070] One or more steps of the methods in the embodiments provided herein can be derived from... Figure 4 The corresponding unit or module provided will be executed. Figure 4 Units or modules in devices such as ED 110, T-TRP 170, or NT-TRP 172 are illustrated. For example, signals may be transmitted or output by a transmitting unit or transmitting module. Signals may be received or input by a receiving unit or receiving module. Signals may be processed by a processing unit or processing module. Other steps may be performed by an artificial intelligence (AI) module or a machine learning (ML) module. The corresponding units or modules may be implemented using hardware, one or more components or devices executing software, or a combination thereof. For example, one or more units or modules may be circuits such as integrated circuits. Examples of integrated circuits include programmable FPGAs, GPUs, or ASICs. For example, one or more of these units or modules may be logical functions, such as logical functions executed by circuits, by a portion of an integrated circuit, or by software instructions executed by a processor. It should be understood that if these modules are implemented using software executed by a processor, etc., then these modules may be retrieved by the processor, wholly or partially, individually or collectively, for processing, or in one or more instances as needed, and these modules themselves may include instructions for further deployment and instantiation.

[0071] Although not shown, the transmitting module and the receiving module can be part of a transceiver module, or combined into a transceiver module. A transceiver module can also be called an interface module, or simply an interface, and is used for input and output operations.

[0072] Further details regarding ED 110, T-TRP 170, and NT-TRP 172 are known to those skilled in the art. Therefore, these details are omitted herein.

[0073] After a broad discussion of communication above, the following text will turn its attention to specific exemplary embodiments.

[0074] As mentioned above, hybrid service codecs consider multiple services (at least two services) with different service types. One service type can be protected by a small code (small code length), while another service type, due to its large payload, can be protected by a large code. An example of hybrid service codecs is to embed some or all of the information bits from the small code into the payload of the large code and encode them together in the large code. Decoding the small code can enhance the decoding of the large code, and if the small code cannot be decoded independently, decoding the large code can also improve the reliability of the small code, thereby reducing the possibility of small code retransmission.

[0075] Small (or smaller) code (or code length) can also be called short (or shorter) code (or code length). Similarly, large (or larger) code (or code length) can be called long (or longer) code (or code length). In hybrid service encoding and decoding where some or all of the bits associated with the first code are embedded in the payload of the second code, the bits of the combined payload (including the embedded bits) are encoded together in the second code.

[0076] Some aspects of this disclosure add a process between decoding failure and retransmission request. This is achieved by integrating various services into a single FEC, while taking into account service priorities (target BLER, delay, and source). Some aspects of this disclosure relate to channel coding / decoding designs that simultaneously support self-decoding capabilities and enhanced joint decoding capabilities.

[0077] Integrating various services into a single forward error correction (FEC) code is one example of integration. Implementations are not limited to different services in any way. More generally, payload types such as control information and data can be integrated into a single FEC code, or encoded within a single block or payload. Self-decoding capabilities and enhanced joint decoding capabilities are examples of other features that may be provided or supported in implementations.

[0078] Some aspects of this disclosure relate to a three-stage decoding attempt transmission method. This method may include a process called joint decoding, which is interposed between decoding failures and retransmission requests.

[0079] The three-attempt decoding transmission paradigm is an example of a method where multiple decoding attempts can be made before a retransmission request is requested. Joint decoding is an example of a process where attempts can actually be inserted or made between decoding failures and retransmission requests.

[0080] Figure 5 Self-decoding (left) and joint decoding (right) are shown and referenced below in the content about this example.

[0081] In the first decoding attempt, the receiver decodes the first payload after receiving the corresponding Minimum Required Code (LLR). If the decoding of the first payload is successful, the receiver uses the correctly decoded bits to enhance the decoding performance of the second payload after receiving the corresponding LLR.

[0082] The first payload is self-decoding, and the minimum required coded bits refers to the minimum number of coded bits required to decode the first payload. LLR stands for Log-Likelihood Ratio, which is an illustrative example of coded bits. Figure 5 The successful decoding of the first payload is shown at position 500. Figure 5 It also shows that correctly decoded bits can be used to enhance the decoding performance of the second payload. The minimum required number of encoded bits for the second payload refers to the minimum number of encoded bits required to decode the second payload.

[0083] The bits in the codeword generated through encoding can be primarily referred to as encoded bits, encoded bits, or coded bits in this paper. For example, the bits input for encoding or to be encoded can be called input bits.

[0084] In the second decoding attempt, if decoding of the first payload fails, the receiver will not request a retransmission but will continue joint decoding with the second payload. This joint decoding feature helps ensure that the first payload will be decoded successfully with a high probability after decoding the second payload (whether successful or not).

[0085] Figure 5 The second decoding attempt is shown at position 510.

[0086] In the third decoding attempt, if decoding of the first payload fails after the second attempt, the receiver requests a retransmission from the transmitter. This causes some delay, but the receiver performs a third decoding using the combined codeword and the retransmitted codeword.

[0087] More generally, for retransmitted codewords, multiple decoding attempts can be made to perform self-decoding from the retransmitted codewords, joint decoding from a portion of the retransmitted codewords, and / or joint decoding using previously received codewords and the retransmitted codewords.

[0088] Some aspects of this disclosure relate to a self-decoding joint codec design such that each individual payload (e.g., corresponding to a service) is self-decoding, while supporting joint decoding to further enhance performance.

[0089] Individual payloads can (but not necessarily) be associated with different services. Other examples of individual payloads include control information and data.

[0090] The following is an illustrative example of a self-decoding joint codec design:

[0091] 1. Embed several small messages into a longer code block;

[0092] 2. Short messages are self-decoding, meaning they can be decoded after a subset of the encoded bits (or symbols, LLRs) has been collected; the subset of encoded bits is also an independent short code.

[0093] 3. Two or more short messages are jointly decodeable; a subset of the corresponding encoded bits is combined into a longer code. This is done by "coupling" bits from the two messages. Specifically, all or a subset of the first message (here, "message" refers to the information bits, i.e., the bits before encoding) is copied and combined with the second message. The combined message is then encoded into a second codeword.

[0094] a. You can directly copy the bits from the first message and append them to the second message;

[0095] b. Bits from the first message can be transformed (e.g., multiplied by a binary matrix) and appended to the second message.

[0096] Although the example uses information bits (or messages) coupling, coupling using coded bits is also feasible. In the case of system code, message bits are also part of coded bits, so the two schemes are equivalent.

[0097] Below is an example of a potential application scenario. The device (e.g., a robotic arm) communicates with the BS and supports URLLC, eMBB, and mMTC services. Video surveillance data transmission falls under the eMBB service, signaling for joint control falls under the URLLC service, and some latency-insensitive perception / monitoring data reporting falls under mMTC.

[0098] Figure 6 The diagram illustrates this example, where the robotic arm 602 includes a video device and two joints and communicates with the BS604.

[0099] According to a method that can be called enhanced eMBB encoding / decoding, a joint code block includes symbols / bits corresponding to URLLC packets, eMBB packets, and mMTC packets. Each URLLC packet, eMBB packet, or mMTC packet is self-decoding. Typically, URLLC bits / symbols are placed at the beginning of the code block, followed by eMBB bits / symbols, and then mMTC bits / symbols.

[0100] The decoder first attempts to decode short packets (e.g., URLLC). If the URLLC packet can be successfully decoded, its coupling bits in the eMBB packet can enhance eMBB decoding. The decoder can then choose to decode either the eMBB packet or the mMTC packet. If the eMBB packet is decoded successfully, the mMTC packet can be decoded with a lower probability of error; otherwise, if the mMTC packet is decoded successfully, the eMBB packet can be decoded with a lower probability.

[0101] After the first packet is successfully decoded, the enhanced decoding of the second packet benefits from the coupling of information bits or coded bits between the two packets. In the case of coupled information bits, the other packet will have fewer information bits, but its packet length remains the same, meaning a lower bit rate. In the case of coupled coded bits, the other packet will have shorter coded bits known in advance by the decoder, also meaning a lower bit rate. In both cases, the bit rate of at least one other self-decoding codeword (such as eMBB) can be reduced, thereby improving performance.

[0102] In the example above, the pre-known encoded bits are the encoded bits obtained by decoding the first packet.

[0103] Figure 7 A block diagram illustrating exemplary code blocks and encoded symbols is shown. Figure 7 And similarly as described below Figure 8 and Figure 9 In the diagram, 700 represents a code block or combined payload, which includes individual payloads 702, 704, 706, 708, and 710. Individual payloads 702, 704, 706, 708, and 710 include payloads associated with different services in the example shown. Code block 700 is channel-coded to generate codeword 720 for transmission. Codeword 720 is generated by encoding the individual payloads using error-correcting codes. Polar codes or braided codes are shown as an example of an eMBB individual payload. Other codes (including different codes for different individual payloads) are also possible. The codeword 720 shown also includes N symbols, but these symbols are only intended as illustrative examples of a portion of the codeword. The arrangement of symbols shown at 720 is also intended to illustrate a possible decoding order. Figure 7 And similar Figure 8 and Figure 9 This should be explained accordingly.

[0104] The code block shown at 700 can be referred to as a combined code block or a joint code block because it comprises individual payloads, blocks, or bits corresponding to the URLLC, eMBB, and mMTC services in the illustrated example. URLLC, eMBB, and mMTC coded symbols represent transmitted or received information about coded bits (parts of a codeword). Coded symbols can be referred to by any of various names or terms, such as packet, block, code, subcodeword, signal, LLR, resource element (RE), etc. For ease of reference, this disclosure refers primarily to coded bits, coded symbols, or coded blocks when referring to portions of a codeword.

[0105] In codeword 720, the URLLC, eMBB, and mMTC encoded symbols are self-decoding. After the encoded bits of each encoded symbol are received, the symbol can be decoded even before the entire codeword 720 has been received, in the case of the URLLC and mMTC encoded symbols in the illustrated example. For example, in the first decoding attempt, a self-decoding symbol can be decoded independently of other encoded symbols, and can also be decoded jointly with one or more other encoded symbols, which can (but do not necessarily have to be) self-decoding symbols as disclosed herein.

[0106] Self-decoding and joint-decoding can be referenced in data before or after channel encoding / decoding. For example, a short code or block that is part of a longer codeword can be considered self-decoding because the block is decodeable on its own, independent of the rest of the longer codeword. The data encoded to generate that short code or block (e.g., also referred to herein as a separate payload) can be considered self-decoding because the separate payload can be self-decoded from that short code or block. For example, whether in an uncoded payload or in a coded symbol or packet, "decoding" is intended to represent the same meaning, specifically that a separate payload and a combined payload can be decoded from a codeword, or equivalently, that a codeword can be decoded to recover a separate payload and a combined payload. In other words, the payload (information bits) and the coded block or packet (coded bits) can be deterministically converted to each other. The payload / information bit or the packet / coded bit can be referred to as decoding or encoding.

[0107] For example, in Figure 7 In this code block 700, URLLC individual payloads 702 and 704 are placed at the beginning of the code block 700, so that these latency-sensitive payloads can be decoded first, followed by the decoding of eMBB individual payload 706, and then the decoding of mMTC individual payloads 708 and 710.

[0108] At the receiver, the decoder first attempts to decode URLLC encoded symbols or short packets. Figure 7 The symbols are labeled as symbols 1 and 2. For illustrative purposes, the URLLC individual payload is shown as encoded into a corresponding self-decoding coded symbol, but in other embodiments, the encoding is type-of-service, and 702 and 704 are considered as a single payload and can be self-decoded together into a single payload. If the URLLC packet can be successfully decoded, the URLLC bits from or decoded from that packet can assist or enhance the decoding of one or more other packets, or more generally, the decoding of one or more other blocks or sub-codewords of long codeword 720. For example, the encoded or decoded URLLC bits can be coupled into the eMBB individual payload 706, and / or one or more eMBB encoded packets (including symbols k, k=1, ..., N-1, N in the illustrated example). The coupled bits can enhance the decoding of one or more eMBB packets. After URLLC decoding, the decoder can then decode one or more eMBB packets or decode one or more mMTC packets (including symbols i and i+1 in the illustrated example). If the decoder attempts to decode one or more eMBB packets after URLLC decoding and the eMBB decoding is successful, one or more mMTC packets can be decoded with a lower probability based on any coupled eMBB bits. Otherwise, if the decoder attempts to decode one or more mMTC packets after URLLC decoding and the decoding is successful, one or more eMBB packets can be decoded with an even lower probability based on any URLLC and / or mMTC bits coupled in the individual eMBB payload 706 or one or more eMBB packets. Figure 7 In the example shown, the arrangement of the encoded packets at 720 illustrates an embodiment that supports URLLC decoding, followed by mMTC decoding, and then eMBB decoding, but this is not the only possible decoding order.

[0109] After successfully decoding the first packet (which in the above example may include one or more URLLC packets and / or one or more mMTC packets), enhanced decoding of the second packet (which in the above example may include one or more eMBB packets) is achieved by coupling information bits and / or coded bits between the individual payload and / or packets. For example, in the case of coupled information bits, the decoded enhanced packet is generated from fewer information bits of the individual payload, but the packet length remains unchanged, which results in a lower bit rate. In the case of coupled coded bits, the decoded enhanced packet actually has shortened coded bits known in advance by the decoder, which also results in a lower bit rate. In both cases, regardless of whether information bits, coded bits, or both are coupled between packets, the reference bit rate can be reduced. Figure 7The example described uses the bitrate of one or more eMBB packets to enhance decoding. This can provide improved decoding performance by increasing the probability of successful decoding.

[0110] It should be noted that one or more packets that provide or support decoding enhancement through inter-packet coupling can also be self-decoding. Bit coupling between packets does not mean that enhanced decoding must depend on the previous successful decoding of the coupled bits. For example, regardless of whether the decoding of URLLC and / or mMTC packets is successful, refer to... Figure 7 One or more eMBB packets in the described example may be self-decoding.

[0111] In what can be called HARQ-free URLLC, one option is that if a self-decoding packet (such as URLLC) fails to decode, the receiver continues decoding another self-decoding packet (such as eMBB) instead of requesting a retransmission. If the latter self-decoding codeword is successfully decoded, the bitrate of the former can be reduced, thereby improving performance. Another option is that if a self-decoding packet (such as URLLC) fails to decode, the receiver continues joint decoding of the entire codeblock consisting of URLLC, eMBB, and mMTC instead of requesting a retransmission. If the joint codeword is successfully decoded, all bits can be correctly recovered.

[0112] Figure 8 The entire code block in (discussed below) consists of URLLC, eMBB and mMTC, but this is only an illustrative and non-limiting example.

[0113] There are two modes of coupling between URLLC symbols and eMBB symbols. The first is called tight coupling, which is coupled within a single time slot or code block. The second is called loose coupling, which is coupled between two consecutive time slots or code blocks.

[0114] Tight coupling and loose coupling can be referred to by other names; these are just examples of how to refer to different types, degrees, or strengths of coupling.

[0115] Figure 8 Exemplary code blocks and encoded symbols are shown. Code block 700 and encoded symbol 720 are... Figure 7 The same as shown, but Figure 8 Different decoding methods are shown at 800, serving as an example of HARQ-free URLLC. If a self-decoding packet (e.g., for URLLC) fails to decode, the receiver can continue decoding another self-decoding packet (for eMBB or mMTC, where...). Figure 8(Taking mMTC as an example), instead of requesting a retransmission. If the subsequent self-decoding packet is successfully decoded, the bit rate of the previous packet can be reduced based on the coupling bits from the subsequent packet, thereby improving performance. Another option is that if the self-decoding packet (e.g., for URLLC) fails to decode, the receiver can continue to jointly decode the entire joint codeword 720 to recover the entire code block 700, instead of requesting a retransmission. If the joint codeword 720 is successfully decoded, all bits at 700 can be correctly recovered. Figure 8 In one example shown at 800, if both URLLC decoding and mMTC decoding fail, joint decoding can still succeed.

[0116] Tight coupling within a time slot or a combined code block or joint code block 700, such as Figure 8 As shown. To achieve joint decoding, there is coupling between individual payloads or coding blocks within a code block 700 or codeword 720. For example, tight coupling may be preferred because it supports joint decoding based on a single time slot or a portion of a single joint codeword rather than portions of multiple time slots or multiple codewords.

[0117] In a method that can be called HARQ-free URLLC using IR combining, the receiver requests a retransmission using incremental redundancy HARQ only if the second decoding attempt fails again. The retransmission includes the incrementally encoded bits of the first message (URLLC in this example) because successful decoding of the first message increases the probability of successful decoding of subsequent messages. Optionally, the retransmission may also include the incrementally encoded bits of subsequent messages to further enhance decoding performance.

[0118] Upon receiving the retransmitted bits / symbols, the receiver will perform a similar decoding attempt as described above.

[0119] Figure 9 Another exemplary code block and encoded symbol are shown. Code block 700 and encoded symbol 720 are shown with... Figure 7 and Figure 8 The same as shown, but Figure 9 Different decoding methods are shown at 900, serving as an example of HARQ-free URLLC employing incremental redundancy (IR) merging. In some embodiments, multiple decoding attempts can be made without requesting retransmissions, such as... Figure 7 and Figure 8 As shown, if these decoding attempts fail, the receiver can request a retransmission using incremental redundancy HARQ. This type of method can still be called "HARQ-free" in the multiple decoding attempts before the receiver sends and the transmitter receives the first retransmission request, and the HARQ-free URLLC using IR, as described above, adds a retransmission request option after multiple unsuccessful decoding attempts.

[0120] Retransmissions should ideally include incremental redundancy information, such as the first message ( Figure 9 The incremental encoded bits for URLLC in the illustrated example are used because the successful decoding of the first message increases the probability of successful decoding of subsequent messages. Optionally, retransmissions may additionally or alternatively include incremental redundancy information, such as incremental encoded bits for subsequent messages, to further enhance decoding performance. For both URLLC and mMTC in the illustrated example, IR decoding based on incremental encoded bits is typically indicated by "IR Decoding" at 900.

[0121] After receiving the retransmitted encoded bits, the receiver can perform a decoding attempt similar to that described in the example above.

[0122] Regarding requests and retransmissions, consider the traditional HARQ method implemented via ACK and / or NACK signaling, and up to four redundant versions (RV1, RV2, RV3, RV4) for the retransmission option. NACK signaling can be viewed as a form of retransmission request; in response to this request, the transmitter sends a retransmission including a redundant version of the previously transmitted data. In this type of method, NACK is sent by the receiver after the first decoding failure.

[0123] Before requesting a retransmission, a second decoding attempt is made via NACK signaling or other means (“HARQ-free”). This can include behavior or characteristics at one or both of the encoder / transmitter and decoder / receiver.

[0124] In these NACK / NACK-2 examples, whether to use NACK or NACK-2 to request a retransmission is determined by the decoder or receiving device. The device may send both NACK and NACK-2 after multiple decoding failures, or it may skip NACK entirely on the first decoding failure. How to utilize the difference between NACK and NACK-2 is determined by the sending device. For example, in resource-constrained situations, NACK-2 retransmissions may be prioritized, or in resource-sufficient situations, NACK and NACK-2 may be treated equally.

[0125] The retransmission process can be different, either separately or alternatively. For example, in addition to or replacing the redundant versions RV1 to RV4 in the conventional HARQ method described above, one or more new redundant versions or joint retransmission versions can exist to indicate whether the retransmission is an independent RV (as in the conventional example above) or embedded in the incoming payload or packet through joint coding (e.g., joint decoding of URLLC packets or payloads in incoming eMBB packets). The latter type of embedded retransmission can be called a joint retransmission version or J-RV, for example, to enable the decoder or receiving device to determine whether the retransmission is an independent RV or a J-RV.

[0126] Other appendices in this article Figure 1 Sample, Figures 7 to 9 Illustrative, non-limiting examples are provided. Various variations are possible. For example, the individual payloads of different packets can be ordered according to any of a variety of criteria, such as their priority or urgency. It may be preferred to decode the individual payloads first for more urgent services (such as URLLC), and accordingly, these individual payloads may be placed at the beginning of the combined payload shown. The encoded bits of these individual payloads will then be sent, received, and decoded before other payloads.

[0127] Other criteria can be considered alternatively. For example, individual payloads and / or corresponding packets can be ordered based on data or packet size. For instance, packets with smaller messages (fewer information bits) or fewer encoded bits can be placed, sent, and received / decoded first. This allows for a smaller decoded LLR buffer because the first received packet can be decoded quickly, and the corresponding LLR can subsequently be flushed from the buffer.

[0128] There are several possible methods for performing self-encoding and decoding, as well as joint encoding and decoding. In fact, packets can be coupled through chained structures or star-shaped structures.

[0129] Self-decoding and joint decoding can include or involve self-decoding and joint decoding, which can be provided or supported in any of a variety of ways. The examples above refer to packets, but more generally, payloads or packets can be coupled according to sequential or chained structures, or through star topologies, etc.

[0130] The first method of performing self-encoding and joint encoding / decoding is called continuous embedding. The encoding process is as follows:

[0131] - Take K1 information bits (e.g., URLLC) and encode them into N1 coded bits, with a code rate of R1 = K1 / N1.

[0132] - Take K'1 bits (from K1 bits, so K'1 ≤ K1) and K2 additional bits (e.g., eMBB), K'2 = K'1 + K2, and encode them into N2 coded bits.

[0133] - The bit rate is R2=K'2 / N2>R1

[0134] - Take K''2 bits (from K''2 bits, so K''2 ≤ K'2) and K3 additional bits (e.g., mMTC), K''3 = K''2 + K3, and encode them into N3 coded bits.

[0135] - The bit rate is R3 = K''3 / N3 > R2

[0136] - And so on: more payloads can be included in the same way as described above.

[0137] These encoding processes, such as Figure 10 As shown.

[0138] Figure 10 This illustrates the sequential coupling of bits between individual payloads according to a sequential or chained structure. This encoding method, which provides or supports self-decoding and joint decoding, can also be referred to as sequential embedding, to embody the concept that information bits from one individual payload are embedded into information bits of another individual payload or otherwise combined with information bits of another individual payload.

[0139] exist Figure 10 In the example shown, K1 information bits (e.g., associated with a URLLC service) are encoded into N1 coded bits at a code rate of R1 = K1 / N1. Of these K1 information bits, K'1 bits (K'1 ≤ K1) are prepended to K2 additional bits of a different individual payload (e.g., for eMBB). The prepended bits can be as shown, but in other embodiments, they can be appended to the information bits of a different individual payload or otherwise combined with the information bits of different individual payloads. The combined K'2 = K'1 + K2 bits are encoded into N2 coded bits at a code rate of R2 = K'2 / N2 > R1. By prepending K''2 bits (K''2 ≤ K'2) from the K'2 bits and K3 additional bits from a different individual payload (e.g., for mMTC) in the example shown, the resulting K''3 = K''2 + K3 bits are encoded into N3 coded bits. The code rate is R3 = K''3 / N3 > R2. A joint codeword consists of N1 coded bits, N2 coded bits, and N3 coded bits. This type of sequential or consecutive embedding can be repeated for more individual payloads, or in some embodiments, there may be fewer than three individual payloads.

[0140] The second method of performing self-encoding and joint encoding / decoding is called many-to-one embedding. The encoding process is as follows:

[0141] - Take K1 information bits (e.g., URLLC) and encode them into N1 coded bits, with a code rate of R1 = K1 / N1.

[0142] - Take K2 information bits (e.g., mMTC) and encode them into N2 coded bits, with a code rate of R2=K2 / N2.

[0143] - And so on: more payloads can be encoded into packets in the same way.

[0144] - Take K'1 bits (from K1 bits, therefore K'1≤K1), K'2 bits (from K2 bits, therefore K'2≤K2), and the other bits to combine them into K'' x 1 bit. K'' x bits and K x Each additional bit (e.g., eMBB) is integrated into K' x =K'' x +K x 1 bit, and encoded as N x coded bits

[0145] - Bitrate is R x =K' x / N x >R1, R x >R2, and so on.

[0146] These encoding processes, such as Figure 11 As shown.

[0147] Figure 11 This illustrates a many-to-one coupling of bits between what can be called individual payloads, based on a star topology. This encoding method, which provides or supports self-decoding and joint decoding, can also be referred to as many-to-one embedding, where information bits from multiple different individual payloads are embedded into information bits of another individual payload or otherwise combined with information bits of another individual payload.

[0148] exist Figure 11 In the example shown, K1 information bits (e.g., associated with a URLLC service) are encoded into N1 encoded bits at a code rate of R1 = K1 / N1, and K2 information bits (e.g., associated with an mMTC service) are encoded into N2 encoded bits at a code rate of R2 = K2 / N2. This process can be repeated if there are more than two separate payloads to be coupled to another separate payload. K'1 bits (K'1 ≤ K1) of the K1 information bits, K'2 bits (K'2 ≤ K2) of the K2 information bits, and some or all of the information bits from any other separate payloads to be coupled, are embedded into the K1 bits of the different separate payloads (e.g., for eMBB). x An additional bit. The embedded bit can be prepended as shown, but in other embodiments, the embedded bit can be appended to different individual payload information bits or otherwise combined with different individual payload information bits. The combined K' x =K'' x +K x Each bit is encoded as N x coded bits, code rate Rx =K' x / N x >R1, R x >R2, etc.

[0149] Figure 10 and Figure 11 An example of coupling is shown, where one or more common bits couple one or more self-decoding coded blocks to one or more other coded blocks. Figure 10 In this process, common bits are sequentially embedded between the corresponding individual payloads in the combined payload corresponding to the codeword, according to the order of the individual payloads. These individual payloads are encoded to generate self-decoding coded blocks (e.g., K1 bit blocks) and one or more other coded blocks in the codeword. Figure 11 In this process, common bits are embedded from the corresponding separate payloads of one encoded block (e.g., a K1 bit block) and another encoded block (e.g., a K2 bit block) into a separate payload that is encoded to generate a single encoded block (located in the example shown). Figure 11 (Bottom).

[0150] These are just examples; other types of coupling between individual payloads and / or coding packets are also possible, including combinations. Figure 10 Sequential or continuous coupling in Figure 11 The coupling method involves many-to-one coupling. For example, in this hybrid coupling method, a first individual payload can be encoded according to sequential coupling, and a second individual payload can be encoded according to many-to-one coupling.

[0151] Coupling is not limited in any way to common bits between different individual payloads, and common bits may additionally or alternatively be common to the coded block. For example, in a similar manner... Figure 10 The example in the text, but applied to methods of encoding bits, allows for the continuous embedding of common bits between a self-decoding block (e.g., an N1-bit block) and one or more other coded blocks, based on the order of the self-decoding coded blocks and one or more other coded blocks in the codeword. Similarly, considering the many-to-one coupling of coded blocks, common bits can be embedded from a self-decoding block (e.g., an N1-bit block) and one or more other coded blocks (e.g., an N2-bit block) into a coded block (e.g., an N1-bit block) that is encoded to generate a coded block. Figure 11 The bottom N x In (bit block).

[0152] For example, embedding can be applied only between some rather than all of the individual payloads, and / or a combination of the two methods can be applied.

[0153] Variations in the encoding of information bits are also possible.

[0154] In the Figure 10 and Figure 11 When encoding information bits, all information bits can be encoded using the same or similar types of codes, or different codes can be used for different individual payloads. This can also be applied more generally, either alternatively or as an alternative, to the encoding of individual payloads.

[0155] The aforementioned hybrid service encoding and decoding process can also be applied to the joint encoding of control and data information. However, in many scenarios, control and data information can be encoded using different encoding and decoding types. For example, control information can be encoded using polar codes and typically decoded using a hard-decision decoder, while data information can be encoded using LDPC codes and can be decoded using a soft-in, soft-out decoder. Some examples in this disclosure describe a method for jointly encoding control and data to enhance the reliability of control information. Furthermore, the control channel can also be encoded and transmitted separately to maintain self-decoding capability. A common example of the application of joint encoding of control and data is its use in UCI and UL data (UL-SCH) multiplexing.

[0156] This disclosure is not limited to polar codes and low-density parity check (LDPC) codes. For example, soft-output iterative decoding codes include convolutional codes, turbine codes, LDPC codes, product codes, and braided codes. Hard-output continuous decoding codes include polar codes, polarization-adjusted convolutional (PAC) codes, Reed-Muller (RM) codes, Bose–Chaudhuri–Hocquenghem (BCH) codes, and Reed-Solomon (RS) codes.

[0157] In an exemplary communication system, UCI can be multiplexed with UL-SCH on the PUSCH channel. PUSCH refers to the Physical Uplink Shared Channel, which is a physical channel primarily used for transmitting uplink data. PUCCH refers to the Physical Uplink Control Channel, which is the primary physical channel used for transmitting control information. UCI stands for Uplink Control Information. UL-SCH is the Uplink Shared Channel, which is a transport channel containing uplink data information. In this disclosure, UL-SCH can refer to the uplink data information to be transmitted by the UE. NR supports multiple coding chains for different UCI contents. A typical coding chain on UCI may include:

[0158] 1. HARQ-ACK (referring to HARQ feedback information)

[0159] 2. CSI - Part 1 (CRI, RI, CQI First TB, etc.)

[0160] 3. CSI - Part 2 (PMI, CQI 2TB, LI, etc.).

[0161] At least as stated above, UL-SCH is the uplink shared channel, which is the transmission channel containing uplink data information. In some cases, UL-SCH is also used herein to refer to uplink data information to be transmitted by the UE. It should be obvious to those skilled in the art whether the channel or data is being referred to from each instance of UL-SCH.

[0162] In one example, when UCI and UL-SCH are multiplexed, two different priorities (HP, LP) are introduced for UCI and UL-SCH. In another example, UCI and UL-SCH are typically encoded separately, with UCI encoded using polar codes (or small block codes) and UL-SCH encoded using LDPC codes. Different multiplexing rules and rate matching are applied based on the different UCI contents and priorities.

[0163] Figure 12 Typical application scenarios of this disclosure are illustrated. In Figure 12In this communication, Node 1 is typically the UE, and Node 2 is the BS or network device (which could be a gNB, eNB, etc.), although both Node 1 and Node 2 can be general communication devices. During communication, Node 2 can optionally send messages to schedule uplink data transmission first. Scheduling control messages are typically sent in DCI (e.g., in dynamic granting), but they can also be sent in RRC or a combination of RRC and DCI, such as in configuration grant transmissions. The UE can then transmit uplink data, typically using the resources scheduled in the scheduling message. However, at the same time, the UE may need to send other uplink control information in UCI, such as HARQ-ACK, CSI, or a combination of multiple UCI contents. HARQ-ACK and CSI can respond to other transmissions or requests from the BS. For example, HARQ-ACK is HARQ feedback information, typically used to indicate whether the previous downlink data transmission was successful. CSI is channel state information, which can be triggered periodically or aperiodically by the BS. The UE can choose to send UCI in PUSCH instead of all UCI in dedicated control channels such as PUCCH. If the UE also transmits UL data, the UE can send UCI or multiple UCIs along with the UL data in the PUSCH resource; this is commonly referred to as multiplexing. Part of this disclosure describes a method for jointly encoding UCI and PUSCH in the same coding chain (instead of separately encoding UCI and UL data (UL-SCH)) to enhance UCI reliability. As with the separate encoding case, separate UCI coding chains may still exist for transmission. Further details of the joint encoding scheme will be described in this disclosure.

[0164] For clarity, it should be noted that the reference is... Figure 12 The illustration of typical application scenarios of this disclosure does not imply that the embodiments disclosed herein are typical of currently known codec techniques. In this context, typical application is intended to refer to how the embodiments disclosed herein are expected to be applied. Similarly, the statement that node 1 is “typically” a UE refers to the illustrated UL example, in which the transmitting node ( Figure 12 Node 1 in the system is usually the UE.

[0165] When UCI is multiplexed with UL-SCH in PUSCH, this disclosure proposes a joint encoding method for UCI and UL-SCH to enhance UCI reliability. In the joint encoding scheme, some UCI information or encoded bits can be embedded in UL-SCH data for co-encoding. Simultaneously, UCI can be encoded separately, making it self-decoding. The joint encoding scheme has several advantages: First, the UCI payload is relatively small; joint encoding is equivalent to increasing the CB length of UCI, thereby improving reliability. The BS can decode UCI first and eliminate its impact on UL-SCH encoding and decoding; therefore, the joint encoding has minimal or no impact on UL-SCH. Since polar codes use hard-decision decoding and do not require external iteration, the complexity of joint decoding is low.

[0166] Two UCI transmission and encoding / decoding schemes are disclosed, along with detailed designs. Scheme 1 improves the reliability of UCI decoding while minimizing the impact on UL-SCH decoding performance. Scheme 2 is a "HARQ-free" UCI scheme, aiming to achieve reliability similar to UCI content repetition without additional resources or latency.

[0167] Regarding the two target solutions mentioned above, and based on some aspects of this disclosure, the following more specific embodiments are proposed:

[0168] Example 1: All encoded UCI bits are embedded in the UL-SCH, with no additional UCI transmission.

[0169] - Example 2: Embedding a portion of different encoded bits from the mother polar code (partial IR)

[0170] Example 3: Only a portion of high-priority UCI information is enhanced through UL-SCH encoding and decoding.

[0171] Example 4: Rate matching of UCI takes into account the coupled bits and the original UCI encoded bits.

[0172] Various aspects of this disclosure can co-encode a portion of the UCI content with UL-SCH while maintaining the self-decoding capability of the UCI by transmitting separate encoded transmissions for the UCI. The UCI can be a single UCI content (e.g., HARQ-ACK) or a co-encoded combination of multiple UCIs (e.g., HARQ-ACK with Part 1 of the CSI). Multiple UCIs may have different priorities (e.g., HP-ACK and LP-ACK). The coupled UCI bits can be encoded UCI bits or information bits. Since the NR polar code of the UCI is a non-systematic code, and the successive cancellation decoder uses soft input and hard output, embedding encoded bits simplifies decoding. For future generations of wireless communication, the following UCI types can be supported:

[0173] - HARQ-ACK: Used by the UE to send HARQ feedback to the gNB or BS.

[0174] - CSI: Channel State Information, used to report channel quality to help the BS select transmission parameters such as precoder and MCS.

[0175] - SR: The UE uses a scheduling request to notify the BS that the UE has data to transmit and requests the BS to schedule the transmission for the UE.

[0176] - Perception: The UE can communicate with the BS regarding perception parameters or perception results.

[0177] - CG-UCI / UTO-UCI: CG-UCI is the Configuration Granting UCI, used to accompany the Configuration Granting transmission to inform the BS of the parameters used in the Configuration Granting transmission. These parameters may include the HARQ process number, RV, etc. UTO-UCI is the Unused Transmission Opportunity UCI, used by the UE to inform the BS which Configuration Granting resource is not being used by the UE, so that the BS can schedule that resource for other purposes.

[0178] - Joint coding indication: An indication may be sent from the UE to the BS in the UCI to indicate joint coding to be performed between different services or between data and control channels, as described in parts of this disclosure.

[0179] - Other UCI

[0180] More generally, any one or more of these UCI types may be supported in the embodiments.

[0181] Figure 13An example of a joint UCI and UL-SCH encoding / decoding scheme is shown. In this scheme, the original UCI content contains a high-priority (HP) HARQ-ACK (referred to as HP-ACK in this disclosure for simplicity) and a low-priority (LP) HARQ-ACK (referred to as LP-ACK herein). This CSI information is divided into CSI Part 1 and CSI Part 2, and can have three code chains and three code blocks. The high-priority (HP) ACK is encoded using polar codes to generate code block 1 (CB1). CSI Part 1 is encoded using separate polar codes to generate CB2. The information bits of the low-priority (LP) ACK are bundled together with CSI Part 2 and encoded using polar codes to generate CB3. The other information to be transmitted is uplink data information, i.e., UL-SCH. In previous schemes, UL-SCH was encoded separately using LDPC codes.

[0182] exist Figure 13 In the diagram, LP-ACK and CSI Part 2 (CSI-2) are shown at positions 1302 and 1304, respectively. CSI Part 1 (CSI-1) is shown at position 1312, and HP-ACK is shown at position 1322. Figure 13 The top three lines represent three code chains, also known as encoding chains. In the example shown, each encoding chain implements polar encoding / decoding. The third line shows HP-ACK 1322 encoded using polar codes at 1324 to generate CB1. The second line shows CSI-1 encoded using separate polar codes at 1314 to generate CB2. The first line shows the information bits of LP-ACK and CSI-2 encoded using polar codes at 1306 to generate CB3. UCI bit 1332 is a coupling bit, which can include HP-ACK bits from HP-ACK 1322 and / or encoded HP-ACK bits from CB1 1324, as indicated by the arrow at 1300. Figure 13 The bottom line shows the joint encoding of UCI bit 1332 and UL-SCH data 1334 using LDPC code to generate CB4 at 1336.

[0183] In one example of the proposed scheme, some or all of the HP-ACK bits can be embedded into the UL-SCH and jointly encoded using LDPC codes to generate CB4. The bits embedded in the UCI and jointly encoded into the UL-SCH are called coupling bits. Coupling bits from HP-ACK can be embedded as part of the information bits along with the original UL-SCH information bits to form new combined information bits, which are then jointly encoded using LDPC codes. Coupling bits can be some or all of the information bits from the intended UCI (in this case, HP-ACK), or they can be polar-coded bits of HP-ACK. Coupling bits can also be embedded at different positions in the information bit sequence for joint encoding with LDPC codes. For example, coupling bits can be embedded at the beginning of the LDPC code information bit input sequence preceding the UL data input sequence. In another example, coupling bits can be embedded at the beginning of the input sequence after the punctured bits in the LDPC code to avoid puncturing the coupling bits. For example, in NRLDPC codes, the preceding... One information bit was punched, among which... To increase the size, the coupling bits can be placed at the beginning of the data input sequence. After a certain number of bits. In another example, the coupling bit can be placed on a higher-order LDPC variable node, making it generally more reliable in the information bits. In another example, the coupling bit can be placed at the end of the information bit input sequence. In yet another example, the coupling bit can be placed at the beginning of the input sequence and interleaved before encoding; the interleaver can be a pseudo-random interleaver or other type of interleaver.

[0184] Some aspects of this disclosure relate to embedding the entire UCI encoded bit.

[0185] Figure 14 An example of embedding the entire UCI coded bit into UL data for joint encoding is described. In this method, the UCI is first encoded using a polar code (or other code used for UCI encoding), and then all coded bits are embedded as input information bits into the UL data and jointly encoded using LDPC codes. After embedding the encoded UCI bits, an additional separate UCI code chain with the same UCI can be omitted, simplifying the encoding and resource mapping process. In the diagram, HP-ACK is encoded using a polar code, and the entire coded bit is used as a coupling bit, to be embedded together in the UL data as part of the information bits. The combined information bits from the HP-ACK coded bits and the original UL-SCH information bits are jointly encoded using LDPC codes to generate the joint UCI and UL-SCH coded bits. In this example, a separately transmitted HP-ACK code chain may not exist.

[0186] exist Figure 14In the first two lines, the encoded chain is... Figure 13 The same applies. The UCI in the example shown is HP-ACK 1322. The polarization encoding and decoding of HP-ACK 1322 is illustrated by a double arrow at 1400, while the embedding of all polarization encoded bits into UL data 1334 is illustrated by a single arrow at 1400. Figure 14 CB1 is not shown in the diagram to illustrate that in some embodiments, a separate encoding / decoding of HP-ACK 1322 may not be present. CB4 is shown at 1436, which is encoded by UL data 1334 and embedded HP-ACK encoded bits 1432 (e.g., via...). Figure 13 HP-ACK 1322 is generated using LDPC codes (as shown in the example). Even without a separate coding chain for HP-ACK 1322, HP-ACK can potentially be decoded using only the coupled bits, which are transmitted separately as part of the system bits in CB4 in the example shown. However, joint coding of CB4 can significantly improve the decoding probability of HP-ACK 1322.

[0187] To decode UCI and UL-SCH data, the jointly encoded LDPC code can be decoded first. If decoding is successful, both UCI and UL-SCH will be decoded successfully. If decoding fails, the decoder output can still generate soft information (e.g., an external LLR) for the UCI encoded bits to assist in UCI (HP-ACK in this example) decoding. The UCI uses the transmitted UCI encoded bits (which are part of the system bits from the LDPC code output) together with the soft information from the LDPC decoder to decode the UCI. The transmitted UCI encoded bits generate a channel LLR, which can be combined with the external LLR of the LDPC decoder to provide two levels of protection for HP-ACK. After successful decoding of HP-ACK, its effects can be removed from the LDPC code used for UL-SCH encoding and decoding, thereby further improving the LDPC decoding performance of UL-SCH. The UCI used for coupling can be a high-priority UCI content (e.g., an HP-ACK in this example) or a combination of multiple UCI contents. The remaining parts of the UCI content (including the combination of CSI Part 1, CSI Part 2, and LP-ACK) can be encoded into separate code chains using polar codes, such as... Figure 14 As shown.

[0188] Some aspects of this disclosure relate to different parts of the embedded master code encoded bits.

[0189] Figure 15An example is shown of embedding different portions of coded bits from UCI into the UL-SCH for joint encoding. The embedded bits (or coupled bits) can be UCI information bits or coded bits from a UCI coding chain. For the original UCI code chain, the information bits are typically encoded first using a polar code of a specific code length (often called the master code) to generate a set of coded bits encoded from the master code. Then, the actual output coded bits are selected from the set of coded bits output from the master code; this process is often called rate matching. Figure 15 In the example shown, the first part of HP-ACK and CSI is first encoded using a polarized mother code with a specific mother code length M, which is typically equal to... Where n is an integer, such as 512 or 1024. The original UCI coded bits for the output are then selected from the M coded bits of the mother code using a rate matching (RM) process to ensure a specific target code rate is achieved. When coded bits are used for coupling, they can be selected from a subset of the original coded bits of the UCI code chain (in this example, the coded bits of CB1) (this can be viewed as a Chase combining (CC) scheme), or different coded bits can be selected from the mother code of the original polar code (but may overlap with a portion of the coded bits used for UCI transmission) (this can be viewed as a partial IR scheme).

[0190] exist Figure 15 In the diagram, the top row shows the UCI coding chain encoding HP-ACK 1502 and CSI-1 1504 using polarized mother codes to generate polarized mother code output (before rate matching) 1505. The arrow at 1500 is intended to illustrate that the embedding bit (or coupling bit) 1532 of CB4 at 1536 can be a UCI information bit and / or a coded bit from the UCI coding chain, and when coded bits are used for coupling, coded bits can be selected as coupling bits from a portion of the original coded bits of the UCI code chain (in this example, the coded bits of CB1 1506) and / or from the mother code output 1505.

[0191] For some IR schemes, in one example, the encoded bits can be selected from either the beginning or the end of the mother code output. The method for selecting the encoded bits in the mother code output depends on the original rate matching (RM) scheme:

[0192] - For example, if the original RM of the UCI polar code is based on puncturing, such as puncturing at the beginning of the mother code output, then the coupling bits are selected from the beginning of the mother code output.

[0193] - If the original RM method of UCI polar codes is based on shortening, then the coupling bits are selected from the end of the mother code output.

[0194] - If the original RM method of UCI polar codes is based on repetition, then coupling bits are selected from the non-repeating bits.

[0195] If certain coded bits depend only on certain frozen information bits, these bits should be avoided when selecting coupling bits. In some examples, if it is desirable to minimize the impact on UL-SCH, the embedded coupling bits can be punctured in the output of the coded bits. This is because the coupling bits have already been transmitted in the UCI transmission, or have high reliability due to the UCI transmission, so puncturing them allows more other coded bits to be transmitted, thereby improving the UL-SCH decoding performance of the LDPC code.

[0196] Some aspects of this disclosure involve certain high-priority UCI couplings.

[0197] The coupling bits may be only a portion of high-reliability UCI content (such as HP-ACK), rather than all UCI content in the existing UCI code chain. For example, in Figure 16 In this example, only the HP-ACK UCI is coupled with the UL-SCH for joint encoding using LDPC codes. The coupling bits can be either coded bits or information bits. In this example, HP-ACK can be protected multiple times in CB1, CB3, and CB4, which reduces the need for duplication to meet high reliability requirements. In CB3, HP-ACK is encoded independently using its own coding chain. In CB1, it is jointly encoded with other UCI information (part 1 of the CSI and SR in this example) via polar codes. In CB4, it is protected by LDPC codes along with the UL-SCH.

[0198] exist Figure 16 In this process, LP-ACK 1302 and CSI-2 1304 are encoded using polar codes to generate CB2 at position 1306, which can be used in conjunction with... Figure 13 Same as in the text. For example... Figure 16 As shown in the second line, encoding via polar codes can also be essentially the same as... Figure 13 The difference lies in the encoding of HP-ACK 1612, CSI-1 1614, and HP-SR 1616 to generate CB1 at position 1618. HP-ACK also... Figure 16The diagram at 1622 illustrates that HP-ACK is separately encoded using polar codes to generate CB3 at 1624. The "enhanced" label at 1624 is intended to illustrate that, although HP-ACK has already been jointly encoded in CB1, separate encoding of the HP-ACK UCI is added to further protect the high-priority HP-ACK. The coupling bits associated with HP-ACK are shown at 1632 and coupled with UL-SCH data 1334 for joint encoding (e.g., using LDPC codes) to generate CB4 at 1636. The arrow at 1600 indicates that coupling bit 1632 may include encoded bits from CB3 1624 and / or information bits from HP-ACK 1622.

[0199] Some aspects of this disclosure relate to rate matching of polar codes.

[0200] Figure 17 Another example of a joint UCI and UL data coding scheme is shown. In some examples of this disclosure, the selection of the UCI mother code and rate matching can take into account the coupling bits. That is, when performing UCI rate matching and determining the mother code, the code length of the UCI coded bits and the code length of the coupling bits can be considered simultaneously.

[0201] Since the mother code length of a polar code can depend on the code rate of the polar code, for example, depending on the specific number of coded bits required in the output coded bits of CB1, the code length (the number of coded bits output by the mother code) can be 512 or 1024. In some examples of joint UCI and UL-SCH coding schemes, the code length of the polar code mother code can be obtained simultaneously based on the original UCI coded bits and the coupling bits, i.e., the equivalent number of UCI coded bits of the combined coupling bits and the original UCI coded bits in CB1. Similarly, the rate matching scheme used to select the UCI output coded bits from the polar code mother code also depends on the combination of the original UCI coded bits and the coupling bits. After obtaining the combination of the coupling bits and the original UCI coded bits in CB1, a portion of the combined coded bits is used for the coupling bits, and the remainder is used for the original UCI transmission in CB1, as shown in the example.

[0202] exist Figure 17 In the middle, the top line shows how HP-ACK 1702, CSI-1 1704 and HP-SR 1706 are encoded using polarized mother codes to generate the polarized mother code output at 1708. Figure 17 The top row also shows CB1 for transmission at 1710 and coupling bit 1712. In this example, coupling bit 1712 is selected from the polar mother code output at 1708 but is not transmitted in CB1. Figure 17In the process, the original UCI encoded bits and coupling bits 1712 in CB1 at 1710 can also be generated and selected together from the polar code output 1710 based on the rate matching scheme of the polar code. The coupling bits are embedded in the UL-SCH data and encoded using the LDPC code in CB4 at 1736, while the remaining UCI encoded bits at 1710 can be transmitted as CB1. Figure 17 The arrow at 1700 is intended to illustrate that the coupling bit in UCI bit 1732 embedded in UL-SCH data 1734 may include UCI bits from one or more of HP-ACK 1702, CSI-1 1704 or HP-SR 1706 and / or the encoded bit shown as coupling bit 1712.

[0203] Figure 18 A decoding example is shown. The scenario of this example is related to... Figure 17 The example in CB4 is similar. The coupling bits are selected from a portion of the polar code mother code output, which may differ from or be partially different from the original UCI-coded bits in CB1. In the LDPC code output of CB4, the coupling bits may or may not be punctured. As previously stated, decoding can be performed in the following steps:

[0204] Step 1 (optional): Combine the UCI-coded bits into the channel LLR and attempt to decode the polar code (perform this step if the minimum delay of UCI is required, since the polar code can be decoded before receiving UL-SCH information).

[0205] Step 2: If the UCI coupling bits have been decoded from the polarization decoder, allocate a larger LLR as the corresponding coupling bit in the LDPC code used for joint UCI and UL-SCH encoding and decoding, and attempt to decode the LDPC code in CB4.

[0206] Step 3: Send the external LLR of the UCI coupling bits from the LDPC decoder to the polar code decoder. The polar code decoder combines the external LLR with the channel LLR determined based on the received signal of the coupling bits as the reliability input of the polar code, and attempts to decode the polar code again.

[0207] Step 4: If the polar code decoding is successful, use the decoder output as the UCI decoding result and repeat Step 2 (if the polar code decoding fails, stop decoding and do not perform external iterations). Use the LDPC decoder output from Step 2 as the UL-SCH decoding result.

[0208] exist Figure 18In the diagram, step 3 is shown as “CC + External LLR”. Here, CC refers to catch-up merging. Coupled bits can be transmitted as part of the system bits in the original UCI code chains CB1 1710 and CB4 1836. Accordingly, the channel LLRs for the two transmissions of the same coded bits can be merged first, and then an external LLR for the coupled bits generated from the output of the LDPC code in CB4 is added to obtain the input LLR for the coupled bits, which is then used as part of the input to the polar code decoder in CB1. The decoder output is used as the UCI decoding result in steps 2 and 4, as shown in the “hard decision” diagram. Once the polar code decoding in CB1 1710 is successful, the coupled bits become known bits, and a larger LLR value can then be assigned as the input LLR for the coupled bits for LDPC decoding in CB4 1836. Figure 18 Most of the figure labels in the figure are similar to Figure 17 The same applies, except for the following: the arrow at 1800 indicates that the coupling bit may be selected from the polarized mother code output 1708 (and the coupling bit may include the encoded bits in CB1 and / or the encoded bits in the polarized mother code output that are not in CB1); the coupling bit at 1834 may also include the encoded bits in CB1 and the encoded bits in the polarized mother code output that are not in CB1; CB4 at 1836 is generated by the coupling bit embedded in UL-SCH bit 1734 and may include the encoded bits in CB1 and / or the encoded bits in the polarized mother code output that are not in CB1. Figure 18 The symbol "X" below UCI bit 1834 in the LDPC code indicates a possible punching of the UCI bit in the output bits.

[0209] Some aspects of this disclosure relate to rate matching and resource reuse.

[0210] Figure 19 The general process for determining UCI and UL-SCH encoding / decoding parameters and resource reuse schemes is shown.

[0211] In the first step, the transport block size (TBS) of the uplink data is determined.

[0212] This is Figure 19 It is shown at position 1902.

[0213] Regarding the determination of UL-SCH TBS, the current NR standard ([3GPP TS 38.214 version 17.5.0 section 6.1.4]) provides an example of the process for determining the payload size of UL data (UL-SCH), specifically the process for determining the transport block size (number of information bits in the transport block) of PUSCH:

[0214] The UE should first determine the number of REs (N) within the time slot. RE ):

[0215] - UE first determines a PRB using the following formula The number of REs allocated to PUSCH: ,in, It is the number of subcarriers in the frequency domain of a physical resource block. The number of symbols L allocated to the PUSCH is determined according to Clause 6.1.2.1 of [3GPP TS 38.214] (for scheduled PUSCH) or Clause 6.1.2.3 of [3GPP TS 38.214] (for configured PUSCH). This refers to the number of REs used for DM-RS in each PRB during the allocated duration, including the overhead of the DM-RS CDM group without data, as described in Clause 6.1.2.3 of [3GPP TS 38.214] for PUSCH with configuration authorization, or indicated by DCI format 0_1, DCI format 0_2, or as described in Clause 6.2.2 of [3GPP TS 38.214] for DCI format 0_0. This is the overhead configured by xOverhead in the high-level parameter PUSCH-ServingCellConfig. If not configured... (If the value is 6, 12, or 18), then assume The value is 0. In the case of PUSCH repetition type B, assuming there are no segments, It is determined by the nominal repetition of a duration with L symbols.

[0216] - The UE determines the total number of REs allocated to the PUSCH as follows: :

[0217] - For TB processing across multiple time slots:

[0218]

[0219] in, The total number of PRBs allocated to the UE, where N is the number of time slots used for TBS determination, indicated by numberOfSlotsTBoMS.

[0220] Otherwise, .

[0221] Next, continue with the following steps (2) to (4):

[0222] (2) Unquantified intermediate variables (Ninfo) are obtained using the following formula: ,

[0223] Where R is the target bitrate. These are the modulation order (the number of bits per modulation symbol), which are indicated in the MCS index in the DCI and obtained by mapping the MCS index in the MCS table. It is the number of layers used for transmission (or the number of MIMO layers).

[0224] if

[0225] Use step 3 as the next step determined by TBS.

[0226] otherwise

[0227] Use step 4 as the next step determined by TBS.

[0228] End if

[0229] (3) When In this case, the TBS is determined as follows:

[0230] - The middle number of quantized information bits ,in, .

[0231] - Find the values ​​not less than in Table 5.1.3.2-1 The closest to TBS.

[0232]

[0233]

[0234] (4) When In this case, the TBS is determined as follows:

[0235] - Quantization intermediate number of information bits:

[0236] ,in,

[0237] Furthermore, in the rounding function, a tie will be rounded up to the next largest integer.

[0238] - if

[0239] , in

[0240] otherwise

[0241] if

[0242] , in

[0243] otherwise

[0244]

[0245] End if

[0246] End if

[0247] In some examples disclosed herein, TBS determination can be achieved by considering UCI resources, which reduces the impact on the UL-SCH bitrate (making it closer to the target bitrate). In this scenario, TBS can be determined based on the removal of UCI resources (i.e., the number of resource elements allocated to UL data (UL-SCH)), which is obtained by subtracting the REs allocated to UCI from the REs allocated to all PUSCH resources:

[0248] (UL-SCH)= – (UCI)

[0249] use (UL-SCH) rather than the original Calculate TBS.

[0250] In another example, TBS remains unchanged and is based on the REs allocated for all PUSCHs, without removing the REs allocated for UCIs.

[0251] After determining the TBS, in one example, the UL-SCH payload size can be obtained by removing the size of the UCI coupling bits from the TBS. In another example, the UL-SCH payload size can be obtained directly from the TBS without removing the size of the UCI coupling bits.

[0252] The next step may include determining the UCI payload and UCI rate matching. This step may include determining the UCI payload as shown at 1904, followed by determining the UCI rate matching as shown at 1906. Unlike UL-SCH data—whose payload or TBS is determined based on available resources and the target MCS—the UCI payload size can be given or determined based on the UCI content to be transmitted. For example, if the UCI is a HARQ-ACK, and that HARQ-ACK includes 2 bits used to transmit 2 HARQ feedbacks for 2 TBs (1 bit per TB), then the UCI payload is 2 bits. In another example, if the UCI is a CSI report, the number of bits for the CSI can also be determined based on the number of bits to be reported from that particular CSI format. The UCI rate matching process is determined based on the given UCI payload.

[0253] Some aspects of this disclosure relate to UCI rate matching.

[0254] For UCI rate matching, in some embodiments, the number of coded symbols calculated based on UCI resources may include both UCI coded bits and coupling bits.

[0255] exist Figure 19 In the diagram, the UCI payload is shown at position 1904, and the UCI rate matching is shown at position 1906.

[0256] For example, the number of coded symbols for HARQ-ACK and Part 1 of CSI transmitted in PUSCH can be given by different β offsets as shown in the following two equations, which is similar to the UCI rate matching scheme in [Section 6.3.2.4.1 of 3GPP TS 38.212 V17.5.0], where, and These represent the number of coded modulation symbols per layer used for transmitting the first part of HARQ-ACK UCI and CSI. This is the β offset allocated to UCI, representing the proportion of resources that UCI can occupy on PUSCH resources.

[0257] In the following equation,

[0258] - It is the number of HARQ-ACK bits;

[0259] - This is the number of CRC bits used for HARQ-ACK;

[0260] - This is the number of UL-SCH code blocks used for PUSCH transmission;

[0261] - It is the UL-SCH used for PUSCH transmission. Size of each code block;

[0262] - In PUSCH transmission, it can be used in OFDM symbols ( The number of UCI resource elements transmitted in the data. It is the total number of OFDM symbols for PUSCH, including all OFDM symbols used for DMRS;

[0263] - Scaling configuration is determined by higher-level parameters;

[0264] - It is the symbol index of the first OFDM symbol that does not carry PUSCH in the PUSCH transmission, following the first (or first few) DMRS symbols.

[0265] The calculation method is similar. For a more detailed explanation of the calculation of the number of coded symbols for each UCI, please refer to Section 6.3.2.4.1 of 3GPP TS 38.212 V17.5.0.

[0266]

[0267]

[0268] Resources are preferentially allocated to high-priority UCI. However, in some examples of this disclosure, the number of coded symbols calculated using UCI resources may represent the sum of UCI coded bits and coupling bits used for the joint UCI and UL-SCH decoding scheme, rather than just the UCI coded bits. The number of coded symbols calculated here for UCI, excluding additional coupling bits, can be used directly to generate the number of coded symbols for resource multiplexing and transmission of UCI codes, for example, to generate the number of coded symbols used for HARQ-ACK. The number of encoded symbols is used for resource mapping and transmission in HARQ-ACK. For example, when the calculated number of encoded symbols for UCI includes additional coupling bits, for example... Then the number of coupling bits to be removed, i.e., the actual number of encoded symbols generated by the HARQ-ACK code chain for resource mapping and transmission, should be determined by... A number of coupling symbols are given, where the number of coupling symbols equals the number of coupling bits divided by the modulation order. An additional number of coupling bits can be generated from the HARQ-ACK code chain, which is used to embed into the UL-SCH code chain for joint coding.

[0269] In some embodiments, the next step is UL-SCH rate matching. This step aims to determine the coded bits to be selected in the encoded output. After determining the UL-SCH TBS at 1902, the payload of the UL-SCH data and the embedding coupling bits from the UCI are encoded together. Prior to the rate matching process, there are common encoding steps for UL-SCH data that may not be included in the encoding process. Figure 19The step shown before 1908 in the table may include TB CRC appending, CB segmentation, encoding, etc., prior to the rate matching process. The number of coded bits is determined based on the available REs for transmitting the coded UL-SCH in the PUSCH resource, which is determined during the TBS determination process at 1902. In some examples, this UL-SCH rate matching process is determined without considering UCI multiplexing on the same resource. In this case, the actual number of coded bits transmitted is reduced due to the presence of UCI during the data and control multiplexing process when mapping to time-frequency resources. Figure 19 In the diagram, the UL-SCH rate matching process is shown at 1908, and the label "No UCI" refers to an example where the number of coded bits selected for the rate matching process does not take into account the resources occupied by UCI. In some other examples, the UL-SCH rate matching process may take into account UCI resources when selecting coded bits from the encoded output of the UL-SCH data. For example, the number of coded bits selected from the encoded output may be determined based on the available RE calculated after removing UCI resources, similar to the example of TBS determination considering UCI resources.

[0270] The next step, which can be called data and control multiplexing, is to determine how to map the coded symbols used for UL-SCH data and the coded symbols used for UCI to the time-frequency resources allocated to PUSCH.

[0271] Some aspects of this disclosure relate to data and control reuse.

[0272] exist Figure 19 In the diagram, at position 1910, the mapping of coded symbols to time-frequency resources is shown.

[0273] Mapping UCI and UL-SCH coded symbols to time-frequency resources (REs) can follow a predefined order and rules. In one example, a portion of the UCI bits (e.g., HARQ-ACK bits) are mapped to a fixed reserved allocation. The remaining UCI bits (e.g., part 1 of the CSI) are then mapped to the time-frequency grid. After that, part 2 of the CSI can be mapped. Subsequently, the coded symbols for UL-SCH can be rate-matched to the remaining resources. All mappings can avoid the location of certain reference signals (e.g., DMRS).

[0274] In some examples of the joint coding schemes described in this disclosure, the joint coding of UCI and UL-SCH is treated as UL-SCH in terms of reuse rules.

[0275] In some examples, system coupling bits from the UCI can be mapped separately from the rest of the UL-SCH coded symbols. These coupled bits can be considered part of the UCI coding chain and mapped to UCI resources first to improve reliability. In other examples, the coupled bits can be considered part of the UL-SCH coded symbols and follow the UL-SCH mapping rules.

[0276] Figure 20 An example of resource mapping is shown, where the overall time-frequency resources are represented in a time-frequency grid. Each rectangle in the time-frequency grid typically represents a RE or time-frequency cell. In this resource mapping example, UCI and UL-SCH coded bits are modulated into coded symbols and multiplexed and transmitted on the PUSCH. An example of this coding scheme can be found in [link to example]. Figure 16 A separate coded UCI code chain CB3 can exist. Figure 16 1624), which is dedicated to protecting the most critical UCI content, such as HARQ-ACK in this example. Figure 20 In this context, the resource mapping for this type of CB is shown as "HARQ-ACK with parity bits (coupling bits) on HARQ-ACK resources". HARQ-ACK bits (information bits and / or parity bits) can be embedded into UL-SCH data for joint encoding, such as... Figure 16 As shown in CB4 or 1636. Figure 20 In this context, the resource mapping for this type of CB is called "Joint UCI (HARQ-ACK) and UL-SCH encoded symbols". Other UCI code chains also exist, for example... Figure 16 The code chains CB1 (1618) and CB2 (1306) in the code chain jointly encode different UCI content with the same or different priorities. Figure 20 In this context, the resource mapping for this type of CB is shown as "Joint UCI-coded symbol on UCI resource".

[0277] Regarding resource reuse, in the first step, there may be resource allocations reserved for certain UCI content, for example, Figure 20 The HARQ-ACK resource is shown in the reserved location. In one example of this disclosure, the coded symbols (e.g.,) are modulated using UCI coupling bits (system bits as the output of joint UCI and UL-SCH encoding / decoding). Figure 16 CB4 in the code can be mapped to the corresponding position that corresponds to the position in the UCI code. For example, in Figure 16In the described encoding / decoding example, symbols generated from the HARQ-ACK encoded bits in CB3, and symbols generated from the HARQ-ACK coupling bits in CB4, can both be mapped to HARQ-ACK reserved resources. The HARQ-ACK bits from CB3 can be mapped first, followed by the HARQ-ACK coupling bits, but other orders are also possible. If the encoding / decoding is as follows... Figure 15 As described above, and since all HARQ-ACK encoded bits are coupled bits embedded in the UL-SCH code chain, these HARQ-ACK coupled bits can be mapped to reserved HARQ-ACK positions. Figure 20 In the diagram, the HARQ ACK reserved position is shown as "HARQ-ACK with parity bits (coupling bits) on HARQ-ACK resource". In some other examples, the HARQ-ACK coupling bits can still be considered as part of the UL-SCH code chain, and the mapping method is the same as other UL-SCH encoded symbols.

[0278] After mapping the HARQ-ACK symbols, the second step involves mapping other coded symbols from the UCI code chain to the resources. Mapping can follow a frequency-first, time-later approach, as in... Figure 20 In the example, but other mapping orders can also be used. Figure 16 In the encoding / decoding example, CB1 and CB2 both belong to other UCI code chains, and they are mapped to time-frequency resources based on the importance order of the UCI content. This order can be predefined based on the importance of different UCI content. For example, CB1 can be mapped first, followed by CB2. Figure 20 In the diagram, the mapping of CB1 and CB2 on time-frequency resources is shown as "joint UCI coding symbols on UCI resources" because these two CBs contain joint codes for multiple UCI types, regardless of whether they have different priorities. In some other examples, only one UCI can be encoded on the coding chain, and the resulting CBs can be mapped in the same way as the joint UCI code chain. It is important to note that when mapping to time-frequency resources, some positions may be reserved for other uses; these positions should be avoided as much as possible. For example, in... Figure 20 In this context, DMRS is reserved in certain locations, and these locations should be avoided when mapping UCI resources (as well as UL-SCH resources).

[0279] After all UCI code chains have been mapped, in the third step, UL-SCH symbols from the combined UCI and UL-SCH code chains are mapped to resources. The mapped resources should follow those already mapped by UCI symbols and avoid HARQ-ACK reserved positions and other reserved positions, such as DMRS. In some scenarios, the number of coded symbols generated by the UL-SCH rate matching step described above may be greater than the remaining available REs in the entire PUSCH resource. In this case, the coded symbols can be "rate matched" or "punctured" around UCI and HARQ-ACK reserved resources. For example, if a rate matching scheme is used to avoid UCI resources, UL-SCH coded symbols can be mapped sequentially to the remaining resources by avoiding UCI resources. In another example, if a "puncturing" scheme is used to avoid HARQ-ACK reserved resources, UL-SCH coded symbols can be mapped to the remaining resources, first including HARQ-ACK reserved resources, and symbols mapped to existing HARQ-ACK reserved positions will no longer be transmitted (i.e., these symbols will be punctured). As mentioned earlier, in one example, all joint UCI and UL-SCH encoded symbols can be treated as UL-SCH symbols and mapped accordingly. In some other examples, the UCI coupling bits of the system bits of the joint UCI and UL-SCH code chain can be mapped to the corresponding UCI symbols in the same way. In this case, the remaining symbols in the joint UCI and UL-SCH encoded symbols, excluding the coupling bits, can be mapped to the UL-SCH symbols as described above. Figure 20 In the diagram, this is shown as "Joint UCI (HARQ-ACK) and UL-SCH encoded symbols (excluding coupling bits)".

[0280] Overview

[0281] This document describes various aspects of this disclosure and illustrates them by way of example in the accompanying drawings.

[0282] Figure 21 This is a flowchart of a more general exemplary method according to an embodiment.

[0283] exist Figure 21 In the diagram, 2100 on the left illustrates operations or features that an encoder or transmitting device can provide or support, and 2150 on the right illustrates operations or features that a decoder or receiving device can provide or support. For ease of reference, a device that can implement or support encoding and / or transmitting features may be referred to as a first communication device, while a device that can implement or support decoding and / or receiving features may be referred to as a second communication device. Embodiments may involve one or both of these devices.

[0284] First, refer to the encoding at 2100, 2104, which is intended to represent encoding the input bits to generate coded bits.

[0285] The input bits include data bits (which may include uplink data, such as UL-SCH data) and bits associated with control information. For example, this control information may be UCI. The bits associated with the control information may include control information bits, coded bits generated from the control information (also referred to herein as second coded bits), or both. Reference Figure 13 As an example, the coupling bit at 1332 may include either or both of the HP-ACK bit at 1322 and the coded bits of CB1 at 1324. Other examples of coupling bits are as follows: Figures 14 to 18 As shown, all these examples of coupled bits are examples of bits associated with control information and are part of the input bits encoded at 2104.

[0286] The encoding at 2104 involves jointly encoding the data bits and the bits associated with control information. Consistent with the embodiments disclosed herein, this may involve encoding according to a first code (e.g., Figures 13 to 18 As shown or referenced Figures 13 to 18 The described LDPC code jointly encodes data bits and bits associated with control information, the first code being different from the second code (e.g., Figures 13 to 18 As shown or referenced Figures 13 to 18 The described polar code), the second encoded bit is generated from the control information based on the second code. The first code being an LDPC code and the second code being a polar code are merely examples; other embodiments may involve one or two of these types of codes, or one or more different codes.

[0287] Although there may be different codes for joint encoding of data bits and bits associated with control information (the first code mentioned above) and separate encoding of control information (the second code mentioned above), joint encoding is different from techniques that encode only data and control separately.

[0288] Figure 21 The output encoded bits are shown at 2106. These encoded bits are generated by encoding at 2104 and can be transmitted as shown by the dashed lines from 2106 to 2152.

[0289] In some embodiments, the bits associated with the control information are or include second coded bits generated from the control information. Therefore, it should be understood that although the second coded bits can be generated by encoding the control information separately, these second coded bits may or may not be included in the coupling bits used for joint encoding with the data bits.

[0290] For example, joint encoding and individual encoding of control information can be provided in multiple encoding chains. Therefore, some embodiments may also include encoding the control information according to a second code to generate second coded bits. This is in Figure 21 Not shown separately, it could be, for example, part of the encoding at 2104. The input bits used for this encoding to generate the second encoded bits are control information.

[0291] The output at 2106 may also include outputting a second coded bit. In some embodiments, coded bits from joint encoding and second coded bits from separately encoded control information are output simultaneously. Some embodiments may include transmission bits; correspondingly, a method may include transmitting coded bits in a data channel such as PUSCH. Coded bits generated by encoding control information (also referred to herein as second coded bits) may also be transmitted, and in some embodiments, a method includes transmitting coded bits and second coded bits in the same data channel.

[0292] The example above refers to coded bits from joint encoding and second coded bits generated from control information. Other separate encodings may also exist. For example, Figure 13 , Figure 14 and Figure 16 An embodiment is shown where an additional coding chain exists for control information. This illustrates an embodiment that includes encoding other control information to generate other coded bits (e.g., Figure 13 and Figure 14 CB2 and / or CB3 in, or Figure 16 (CB1 and / or CB2 in the diagram). Other such encoded bits can also be output. To avoid overcrowding in the accompanying diagrams, Figure 21 The separate encoding and output of these other encoded bits are not shown separately, but they may be part of the encoding at 2104 and the output at 2106.

[0293] The first and second codes mentioned above are different codes. Other coding chains (or codes) can be encoded based on other codes that are the same as or different from the first or second code. For example, in some embodiments, encoding other control information includes encoding other control information based on other codes that have the same code type as the second code, or the second code can be used to generate other coded bits from such other control information. Figure 13 , Figure 14 and Figure 16 In the example shown, each control information encoding chain encodes the control information according to the same type of code (polar code in these examples).

[0294] Other control information can be of the same type as the control information used for joint encoding, or it can be of a different type. As an example, other control information can be of the same type as the control information used for joint encoding, but with a different priority. Figure 13 , Figure 14 and Figure 16 An example is shown where the control information used for joint encoding is HP-ACK and other (separately encoded) control information includes LP-ACK. HP-ACK and LP-ACK represent an example of control information of the same type but with different priorities.

[0295] Figure 16 The examples also illustrate an embodiment in which separately encoding other control information (shown at positions 1612, 1614, and 1616 in the second row) includes jointly encoded control information (also shown as HP-ACK at position 1622 in the second row) and additional control information (CSI-1 at position 1614 and HP-SR at position 1616). In these embodiments, encoding other control information includes jointly encoding the control information (e.g., at position 1612) and the additional control information (e.g., at positions 1614 and 1616).

[0296] The coupling bits may include control information bits and / or second coded bits generated from the control information. All or part of the control information bits may be coupling bits, and these coupling bits may also, or alternatively, include all or part of the coded bits generated from the control information. In some embodiments, the second coded bits included in the coupling bits may include a subset of coded bits selected from the set of coded bits generated by encoding the control information. In other words, not all coded bits generated by encoding the control information need to include data bits for joint encoding. Therefore, the set of coded bits may include second coded bits (coupling bits as input bits for joint encoding) and additional coded bits. For example, at least as discussed above, when coded bits from separately encoded control information are used for coupling, the coded bits may be selected from a portion of the original coded bits (e.g., for...). Figure 15 The UCI code chain in the diagram, derived from the complete set of coded bits for separate encoding of the UCI (shown as CB1 at 1506), allows for the selection of coded bits as coupling bits for joint encoding with data bits, supporting chase-combining (CC) during decoding. For example, from... Figure 15 Selecting different encoding bits in the mother code output 1505 can support some IR schemes.

[0297] Some embodiments may include rate matching; correspondingly, a method may include applying rate matching as shown at 2108. Rate matching may include outputting some or all of the coded bits for transmission and may be applied to coded bits from any coding chain. Figure 17 The example shown at 1712 illustrates that, after rate matching, no coded bits from the UCI coding chain are transmitted. Coupling bits can be selected from the complete set of coded bits (including the non-transmitted bits in the example shown). Selecting coupling bits from non-transmitted bits is also an example of selecting one or more bits from the complete set of coded bits based on rate matching.

[0298] More generally, one or more bits can be selected based on rate matching (or in other words, a method may include selecting one or more bits). For example, rate matching may include puncturing, shortening (possibly in combination with puncturing), or repetition. One or more bits may be selected for co-coding with data bits if rate matching includes puncturing, from punctured bits (at the beginning) of the encoded bit set; if rate matching includes shortening, from shortened bits (at the end) of the encoded bit set; or if rate matching includes repetition, from bits other than repetitive bits in the encoded bit set. Figure 17 In the example shown, coupling bits can be selected from the bits shown at 1712, and these coupling bits may include punched bits and / or shortened bits.

[0299] In some embodiments, the dashed lines from 2108 to 2152 illustrate the transmission of rate-matched coded bits, which may include: transmitting rate-matched coded bits from any one or more of a plurality of coded chains (e.g., any one of the coded bits, a set of coded bits generated by encoding control information, or the other coded bits mentioned above).

[0300] Some embodiments may include determining the Transport Block Size (TBS) based on allocated resources and determining the payload size of data bits based on the transport block size. Determining the transport block size may take into account the resources allocated to control information, or may also be based on the bits associated with the control information to determine the payload size.

[0301] Elsewhere in this document, examples of determining the TBS are provided, given in the context of determining the transport block size (the number of information bits used for a transport block) of a PUSCH in the current NR standard ([3GPP TS 38.214 version 17.5.0 section 6.1.4]). Determining the TBS may include first determining the number of REs allocated to the PUSCH within a time slot (consistent with the examples above), specifically by determining the number of REs allocated to the PUSCH within a PRB and determining the total number of REs allocated to the PUSCH. Some embodiments may include determining an unquantized intermediate variable based on the number of REs allocated to the PUSCH and determining the TBS based on that unquantized intermediate variable, possibly by reading the TBS from a table that maps unquantized intermediate variable values ​​to TBS values.

[0302] At least as stated above, TBS determination can be achieved by considering UCI resources, which can reduce the impact on the UL-SCH bitrate (making it closer to the target bitrate). This is one example of how TBS determination considers resources allocated for control information. In another example in this paper, TBS remains constant and is based on REs allocated for all PUSCHs without removing REs allocated for UCI.

[0303] In some embodiments, the payload size can also be determined based on the bits associated with control information. For example, at least as described above, after determining the TBS, the UL-SCH payload size can be obtained by removing the size of the UCI coupling bits (also referred to herein as the bits associated with control information) from the TBS. In another example, the UL-SCH payload size can be obtained directly from the TBS without removing the size of the UCI coupling bits.

[0304] One approach may include determining UCI payload and UCI rate matching, or more generally, control information payload size and control information rate matching. This step may include determining the control information payload size and then determining the control information rate matching, which is related to... Figure 19 The examples shown at points 1904 and 1906 are consistent. The size of the control information payload can be given or determined based on the content of the control information to be transmitted. As illustrated above, if the control information is a HARQ-ACK, and this HARQ-ACK includes 2 bits used to transmit 2 HARQ feedbacks for 2 TBs (1 bit per TB), then the control information payload is 2 bits. In another example, if the control information is a CSI report, the number of bits for the CSI can also be determined based on the number of bits to be reported from that particular CSI format. The control information rate matching process can be determined based on the given control information payload size.

[0305] In the above example, for control information (e.g., UCI) rate matching, the number of coded symbols calculated based on UCI resources or otherwise determined can include both UCI coded bits and coupling bits. Consistent with the HARQ-ACK example above, the number of coded symbols for HARQ-ACK and the first part of CSI transmitted in the PUSCH can be determined based on different β offsets and the two equations provided in the above example, similar to the UCI rate matching scheme in [Section 6.3.2.4.1 of 3GPP TS 38.212 V17.5.0].

[0306] Resource priority can be assigned to high-priority control information such as UCI, but in some examples, the number of coded symbols determined using control information resources can represent the sum of UCI coded bits and coupling bits (also referred to as bits associated with control information in this paper) used for joint coding, rather than individual UCI coded bits. When the number of coded symbols determined for control information does not include additional coupling bits, this number can be directly used to generate the number of coded symbols used for resource multiplexing and transmission of control information, and this number of coded symbols will be generated and used for resource mapping and transmission of control information. When the number of coded symbols determined for control information includes additional coupling bits, the number of coupling bits can be removed. That is, the actual number of coded symbols generated for a separate code chain for control information used for resource mapping and transmission is determined by a smaller number of coupling symbols, where the smaller number of coupling symbols can be equal to the number of coupling bits divided by the modulation order. The additional coupling bit number can be generated from a separate code chain used for joint coding of data embedded in another code chain.

[0307] In some embodiments, the next step is to determine a data rate match to determine the coded bits to be selected in the joint coded output. For example, after determining the TBS, a method may include determining the payload size of data and embedded coupling bits that are jointly coded together. The number of coded bits used for the output may be determined based on the available REs for transmitting jointly coded data and control information in the PUSCH resource, for example, the PUSCH resource is determined during the TBS determination process. In some examples, the data rate matching process for jointly coded data and control information is determined without considering that the control information can be multiplexed on the same resource. In this case, the rate match can be determined such that, when mapped to time-frequency resources, the number of coded bits actually transmitted or otherwise output is reduced due to the presence of the control information through the data and control multiplexing process. The number of coded bits selected for the rate matching process may or may not take into account the resources occupied by the control information. In some other examples, the rate matching process for jointly coded data and control information may take into account the resources occupied by the control information when selecting coded bits from the joint coded output. For example, the number of coded bits selected from the joint encoding output can be determined based on the available RE calculated after removing the control information resources, similar to the example of determining the TBS considering the control information resources.

[0308] The next step may include data and control multiplexing to determine how to map the coded symbols of jointly encoded data and control information, as well as the coded symbols of control information, to time-frequency resources, which in some embodiments are resources allocated for PUSCH.

[0309] Mapping coded symbols to time-frequency resources (REs) can follow a predefined order and rules; this can be referred to as mapping coded symbols to appropriate resources according to the mapping order. According to the mapping order, coded symbols for the second coded bit are mapped to appropriate resources. For example, coded symbols for control information (which, according to some examples in this document, are coded symbols for the second coded bit) are mapped to resources first, and then coded symbols for combined data and control information (which, according to some examples in this document, are coded symbols for the coded bit) are mapped to other resources. This type of mapping order is consistent with mapping UCI first, then UL data, etc.

[0310] Therefore, a method including transmission may include: mapping the encoded symbols of a second encoded bit (separately encoded control information) to a resource for transmitting control information, and after mapping the encoded symbols of the second encoded bit, mapping the encoded symbols of the encoded bit (from joint encoding) to a resource for transmitting data. This differs from a control-first, data-second mapping because in some embodiments, the joint encoded data / control information portion is treated as UL data, and the encoded symbols are mapped to resources according to UL data mapping rules, such as mapping to the last resource, and applying rate matching and / or otherwise avoiding existing control information resources, such as UCI resources. Another difference is that the mapping of coupling bits (also referred to herein as bits associated with control information) can differ from the mapping of the remaining joint encoded bits. Taking system codes as an example, coupling bits (bits associated with control information) can be mapped to control information resources, such as UCI resources, while the remaining joint encoded bits (data and parity bits) are mapped to data resources, such as UL data resources. The mapping to data resources can be performed after the mapping to control resources and can avoid control resources.

[0311] The latter example of resource mapping can be described as follows: both the second coded bit (generated from the control information) and the coded bit (obtained by jointly encoding the data and the bits associated with the control information) include bits associated with the control information. The coded symbols of the second coded bit are mapped to the resources used to transmit the control information, and the mapping of the coded symbols of the coded bit includes coded symbols that map only the coded bits other than those associated with the control information, which have already been mapped to the control resources.

[0312] The resources mentioned above may include or include PUSCH resources.

[0313] Embodiments of this disclosure may provide or support other features, and / or be compatible with... Figure 21 The features shown are different. For example, in some embodiments, the encoded bits generated by encoding at 2104 can be output by the encoder at 2106 for further processing or operation, and can be transmitted or not, as shown by the dashed lines from 2106 to 2152. For example, the encoded bits can be output to a memory.

[0314] like Figure 21As shown at 2102, the acquisition of data and control information for encoding can be performed or supported separately from the encoding at 2104 and / or the output at 2106. The acquisition at 2102 may include any of a variety of operations, such as any one or more of the following: collecting or otherwise receiving data output and / or control information from one or more devices and / or services; accessing data and / or control information in memory; encoding or otherwise preprocessing the data and / or control information (e.g., by selecting coupling bits for joint data / control encoding) prior to the encoding at 2104.

[0315] It may be provided in some embodiments but not in Figure 21 Another example of the features explicitly illustrated relates to signaling. For example, some embodiments may include any of a variety of types of indications relating to sending and / or receiving signaling or encoding and / or transmission. More generally, embodiments may relate to signaling that indicates any of a variety of parameters in a wireless communication network. Parameters relating to one or more of coupling bit selection, encoding, rate matching, transmission, reception, or decoding may be indicated in the signaling.

[0316] Transmission signaling may include an encoder / encoding device or transmitter / transmitting device sending signaling to a decoder / decoder or receiver / receiving device from an encoder / encoding device or transmitter / transmitting device to transmit encoded bits. Transmission may also, or alternatively, include a decoder / decoder or receiver / receiving device receiving signaling from an encoder / encoding device or transmitter / transmitting device. Signaling is not necessarily (or not only) between the communication devices sending or receiving encoded bits. For example, network devices such as gNBs or base stations may send signaling to configure parameters on one or more communication devices. Therefore, a method may include a network device sending signaling, an encoder / encoding device or transmitter / transmitting device receiving signaling from the network device, and / or a decoder / decoder or receiver / receiving device receiving signaling from the network device.

[0317] Figure 21 Various decoding and / or receiving features corresponding to those shown at 2100 are illustrated at 2150. From the perspective of the receiving device, the receiving at 2152 is intended to represent receiving encoded bits generated by encoding input bits, which include data bits and bits associated with control information. The input bits have been jointly encoded according to a first code, which is different from a second code, and the second encoded bits are generated from the control information according to this second code, at least as illustrated above.

[0318] The decoding of the received coded bits is shown at position 2154, and at position 2156, Figure 21The output decoded data bits and the bits associated with control information are shown. The decoded bits can also be referred to as the recovered data bits and the bits associated with control information decoded from the received encoded bits.

[0319] The bits associated with the control information may include control information bits and / or second encoded bits generated from the control information.

[0320] In some embodiments, the transmission includes coded bits from joint encoding and second coded bits generated from control information. Accordingly, a method (or receiving at 2152) may include receiving the second coded bits. A method (or decoding at 2154) may include decoding the second coded bits. Similarly, a method (or output at 2156) may include outputting the recovered control information obtained by decoding the received second coded bits.

[0321] Some embodiments may include joint decoding of coded bits. For example, a method (or decoding at 2154) may include: decoding received coded bits (generated by jointly encoding input bits, which include data bits and bits based on control information) based on recovered control information obtained from decoding the received second coded bits. Reference Figure 18 For example, successfully decoding CB1 (which includes a second encoded bit obtained by separately encoding the control information, in this example, UCI) helps in decoding CB4 (which includes encoded bits obtained by jointly encoding the data bits and the bits associated with the control information). Similarly, successfully decoding CB4 helps in decoding CB1.

[0322] Based on the control information recovered from the decoded second coded bits, the decoding of the received coded bits is consistent with the decoding example above and may include the following steps: Step 1: Combine the channel LLR of the UCI coded bits and attempt to decode the polar code; Step 2: If the UCI coupling bits have already been decoded from the polar decoder, allocate the large LLR as the corresponding coupling bit in the LDPC code used for joint UCI and UL-SCH encoding and decoding, and attempt to decode the LDPC code. In an example of decoding the received second coded bits based on the bits recovered when decoding the received coded bits (from joint encoding), the decoding may include steps 2 and 3: Combine the external LLR of the UCI coupling bits from the LDPC decoding with the channel LLR determined based on the received second coded bits (the signal of the coupling bits) as a reliability input for the polar code, and attempt to decode the polar code.

[0323] Implementations related to receiving and / or decoding may include other features, such as any one or more of the following features (which are also discussed elsewhere herein):

[0324] The bits associated with the control information may be or include second coded bits generated from the control information;

[0325] The first code can be an LDPC code;

[0326] The second code can be a polar code;

[0327] The other control information mentioned above can be of the same (or different) type as the control information;

[0328] Other control information can be of the same type as the control information, but have a different priority.

[0329] Other control information may include control information and additional control information;

[0330] Other coded bits can be generated by jointly encoding control information and additional control information;

[0331] The second set of encoded bits may include a subset of encoded bits from the set of encoded bits generated by encoding control information;

[0332] The set of encoded bits may include second encoded bits and additional encoded bits;

[0333] The second coded bit may include one or more bits selected from the set based on rate matching applied to the set of coded bits;

[0334] In the case of rate matching including puncturing, one or more bits may have been selected from the punctured bits in the set of coded bits;

[0335] In cases where rate matching includes shortening, one or more bits may have been selected from the shortened bits in the set of coded bits;

[0336] In cases where rate matching includes repetition, one or more bits may have been selected from bits other than the repetitive bits in the coded bit set;

[0337] Data bits may include or include upstream data;

[0338] Control information may be or may include UCI.

[0339] A method relating to receiving coded bits and / or decoding coded bits may also provide or support other features, such as receiving or decoding corresponding features of the features described herein in the methods relating to encoding and / or transmitting coded bits.

[0340] For example, additional coded bits can be generated by encoding other control information. Accordingly, a method (or receiving at 2152) may include receiving additional coded bits generated by encoding other control information. A method (or decoding at 2154) may include decoding the additional coded bits. Similarly, a method (or output at 2156) may include outputting the recovered other control information obtained by decoding the received additional coded bits. The additional coded bits may have been generated by encoding other control information according to other codes, which may have the same or different code types as the second code. In one embodiment, the second code is used to encode other control information to generate additional coded bits.

[0341] For example, coded bits can be transmitted in a data channel, and accordingly, a method (or reception at 2152) may include receiving coded bits in the data channel (obtained by jointly encoding data bits and bits associated with control information), and may also include receiving second (and / or other) coded bits in the data channel. An example of a data channel that can transmit coded bits is PUSCH.

[0342] This disclosure includes various embodiments, not only method embodiments but also other embodiments, such as apparatus embodiments and embodiments related to non-transitory computer-readable storage media. Embodiments may be incorporated individually or in combination with the features disclosed herein.

[0343] An apparatus may include a processor configured to cause the apparatus to perform the methods or operations disclosed herein, or to provide or support the features disclosed herein, by means of executing a program. An apparatus may further include a non-transitory computer-readable storage medium coupled to the processor and storing a program for execution by the processor. For example, in Figure 3 In this context, processors 210, 260, and 276 may be or include one or more processors, and each memory 208, 258, and 278 is an example of a non-transitory computer-readable storage medium in ED 110 and TRP 170, 172. For example, a non-transitory computer-readable storage medium need not be provided solely in conjunction with a processor, but may also be provided separately in a computer program product.

[0344] As an illustrative example, a program stored or stored in a non-transitory computer-readable storage medium may include instructions that are used by or cause a processor to be used by, or that a processor, device or other component may otherwise be used to: encode input bits to generate the encoded bits disclosed herein, and output the encoded bits.

[0345] The device embodiments are not limited to the examples described above, nor are they limited to processor-based or program-based embodiments. For example, the device may also or alternatively include: an encoder for encoding input bits to generate encoded bits; and an interface coupled to the encoder for outputting the encoded bits.

[0346] The device may be a communication device or a component implemented within a communication device. For example, a device implemented in a communication device may be an integrated circuit, which may have other names in some cases, such as chip, modem, modem chip, baseband chip, or baseband processor. In some implementations, one or more integrated circuits may be packaged as a system-on-a-chip, system-in-package, or multi-chip module. The device may include one or more integrated circuits, or may include one or more integrated circuits and other discrete components.

[0347] Figure 22 This is a block diagram of an apparatus according to one embodiment. Figure 22 Components of an exemplary device are shown at 2200, in which transmitting and / or encoding features may be implemented; components of an exemplary device are shown at 2250, in which receiving and / or decoding features may be implemented. A controller 2230 may be provided in any of these types of devices. In some embodiments, the device may include transmitting and receiving features, and one or both of encoding and decoding features. Figure 22 In the example shown, the device including all the components shown simultaneously supports encoding and decoding features, as well as transmission and reception features.

[0348] Regarding encoding features and transmission features Figure 22 The example device includes an input interface 2202, an encoder 2204 coupled to the input interface, an output interface 2206, an optional rate matching module 2208, and a controller 2230 coupled to the encoder and the output interface. The controller may also, or alternatively, be coupled to one or more other components, but to avoid overcrowding the figures, these connections are not shown. Figure 22 As shown in the diagram. The data and control information encoded by encoder 2204 are shown as inputs to input interface 2202, and the encoded bits are output through output interface 2206. Although in Figure 22 While shown as a separate component, the output interface 2206 for transmitting or otherwise outputting codewords can be provided, integrated, or coupled to the encoder 2204. Similarly, although in Figure 22 The interface shown is a separate input interface 2202, but the interface used by encoder 2204 to acquire data and control information or input bits for encoding can be provided by encoder, integrated or coupled to encoder.

[0349] In some embodiments, a rate matching module 2208 may be provided, wherein rate matching is applied to the encoded bits before transmission. Figure 22 The transmitter used for transmitting coded bits (which in some embodiments may be rate-matched coded bits) is not shown separately to avoid making the figures too crowded.

[0350] The encoding or transmitting features or functions, as well as other features or functions described herein, can be implemented in any of a variety of ways, such as in one or more components of hardware, firmware, or execution software. This disclosure is not limited to any particular type of implementation, and implementation details may differ between different devices.

[0351] Data and control information or input bits for encoding can be acquired, and encoded bits can be sent or otherwise output through any of a variety of interfaces, including communication interfaces for sending encoded bits or receiving input bits for encoding. The embodiments are not limited in any way to any particular type of interface, and these interfaces can be implemented at least in part based on how data and control information or input bits are acquired and how encoded bits are output.

[0352] In one embodiment, an apparatus includes an encoder (e.g., encoder 2204) for encoding input bits to generate encoded bits as disclosed herein. An interface may be provided and coupled to the encoder, and in the illustrated example, an output interface 2206 is coupled to encoder 2204 to output encoded bits.

[0353] More generally, an apparatus or a component thereof (e.g., encoder 2204 or processor) can be used to encode input bits to generate encoded bits as disclosed herein. An apparatus or a component thereof (e.g., interface 2206 that may be coupled to encoder 2204) can be used to output the encoded bits disclosed herein; or a program may include instructions for outputting the encoded bits disclosed herein, or instructions for causing a processor to output the encoded bits disclosed herein.

[0354] Embodiments associated with such devices or non-transitory computer-readable storage media may include any one or more of the following features, which have also been discussed elsewhere herein:

[0355] The bits associated with the control information may be or include second coded bits generated from the control information;

[0356] The first code can be an LDPC code;

[0357] The second code can be a polar code;

[0358] The device or its components (e.g., encoder 2204) may be used to encode control information according to the second code to generate second encoded bits; or the program may include instructions for encoding control information according to the second code to generate second encoded bits, or instructions for causing the processor to encode control information according to the second code to generate second encoded bits.

[0359] The device or its components (e.g., interface 2206) may be used to output a second encoded bit; or the program may include instructions for outputting a second encoded bit, or instructions for causing the processor to output a second encoded bit;

[0360] The device or its components (e.g., encoder 2204) may be used to encode other control information to generate other encoded bits; or the program may include instructions for encoding other control information to generate other encoded bits, or instructions for causing the processor to encode other control information to generate other encoded bits.

[0361] The device or its components (e.g., interface 2206) may be used to output other encoded bits, or the program may include instructions for outputting other encoded bits, or instructions for causing the processor to output other encoded bits;

[0362] The device or its components (e.g., encoder 2204) may be used to encode other control information according to other codes having the same code type as the second code; or the program may include instructions for encoding other control information according to other codes having the same code type as the second code, or instructions for causing the processor to encode other control information according to other codes having the same code type as the second code.

[0363] Other control information can be of the same type as the control information;

[0364] Other control information can have a different priority than control information;

[0365] Other control information may include control information and additional control information;

[0366] The device or its components (e.g., encoder 2204) may be used to jointly encode control information and additional control information; or the program may include instructions for jointly encoding control information and additional control information, or instructions for causing the processor to jointly encode control information and additional control information.

[0367] The second set of encoded bits may include a subset of encoded bits selected from a set of encoded bits generated by encoding control information;

[0368] The set of encoded bits may include second encoded bits and additional encoded bits;

[0369] The device or its components (e.g., encoder 2204, interface 2206, or rate matching module 2208 coupled to interface 2206) can be used to apply rate matching to a set of coded bits; or the program may include instructions for applying rate matching to a set of coded bits, or instructions for causing the processor to apply rate matching to a set of coded bits.

[0370] The second coded bits may include one or more bits selected from the set based on rate matching;

[0371] In the case of rate matching including puncturing, one or more bits can be selected from the punctured bits of the second encoded bit;

[0372] In cases where rate matching includes shortening, one or more bits may be selected from the shortened bits in the set of encoded bits;

[0373] In cases where rate matching includes repetition, one or more bits may be selected from bits other than the repetitive bits in the coded bit set;

[0374] The device or its components (e.g., encoder 2204, interface 2206, or transmitter coupled to interface 2206) can be used to transmit coded bits and transmit second coded bits in a data channel; or the program may include instructions for transmitting coded bits and transmitting second coded bits in a data channel, or instructions for causing the processor to transmit coded bits and transmit second coded bits in a data channel.

[0375] The device or its components (e.g., encoder 2204, interface 2206, or transmitter coupled to interface 2206) can be used to determine the transport block size based on allocated resources and to determine the payload size of the data bits based on the transport block size; or the program may include instructions for determining the transport block size based on allocated resources and to determine the payload size of the data bits based on the transport block size, or instructions for causing the processor to determine the transport block size based on allocated resources and to determine the payload size of the data bits based on the transport block size.

[0376] Determining the transport block size can be considered as allocating resources for control information;

[0377] The payload size can also be determined based on the bits associated with control information;

[0378] The device or its components (e.g., encoder 2204, interface 2206, or transmitter coupled to interface 2206) may be used to map the encoded symbols of the second encoded bits to a resource for transmitting control information, and after mapping the encoded symbols of the second encoded bits, to a resource for transmitting data; or the program may include instructions for mapping the encoded symbols of the second encoded bits to a resource for transmitting control information, and after mapping the encoded symbols of the second encoded bits, to a resource for transmitting data, or instructions for causing the processor to map the encoded symbols of the second encoded bits to a resource for transmitting control information, and after mapping the encoded symbols of the second encoded bits, to a resource for transmitting data.

[0379] Both the second encoded bit and the encoded bit can include bits associated with control information. In this case, the device or its components (e.g., encoder 2204, interface 2206, or a transmitter coupled to interface 2206) can be used to map the encoded symbols of the encoded bits by mapping only the encoded symbols of the encoded bits other than those associated with control information; or the program can include instructions for mapping the encoded symbols of the encoded bits by mapping only the encoded symbols of the encoded bits other than those associated with control information, or instructions for causing the processor to map the encoded symbols of the encoded bits by mapping only the encoded symbols of the encoded bits other than those associated with control information.

[0380] These resources may be or include PUSCH resources;

[0381] Data bits may include or include upstream data;

[0382] Control information may be or may include UCI.

[0383] Refer again Figure 22 The exemplary apparatus also includes components for providing or supporting receiving and decoding features. These components may be provided separately in the decoding or receiving device or together with other components to provide or support decoding or receiving features as well as encoding or transmitting features.

[0384] Input interface 2256 is coupled to decoder 2254. These components are also coupled to controller 2230, which, at least as described above, may also be coupled to one or more other components. Decoder 2254 is coupled to output interface 2252. Figure 22The diagram also illustrates recovered data and control information output from output interface 2252, with coded bits being input received by interface 2256. Interface 2256 may be provided by, incorporated into, or coupled to decoder 2254. Similarly, interface 2252, which outputs recovered data and control information from the decoder, may be provided by, incorporated into, or coupled to the decoder. In embodiments including rate matching, a de-rate matching module 2258 may be provided to implement corresponding receiver-side features for transmit-side rate matching.

[0385] The decoding-side or receiving-side features or functions, as well as other features or functions described herein, can be implemented in any of a variety of ways, such as in one or more components of hardware, firmware, or execution software. This disclosure is not limited to any particular type of implementation; for example, implementation details may differ between different devices.

[0386] Encoded bits can be received or otherwise acquired, and the recovered bit sequence can be output through any of various types of interfaces, including communication interfaces for receiving encoded bits or sending recovered data and control information. The embodiments are not limited in any way to any particular type of receiver or interface, and their implementation may be at least in part based on how the encoded bits for decoding are acquired and how the recovered data and control information are output. The encoder and decoder interfaces are respectively located in... Figure 22 The diagram illustrates that encoding and decoding features can be implemented independently. However, it should be understood that a single device or apparatus can support both encoding and decoding simultaneously, in which case the encoder and decoder are coupled to the same one or more interfaces at 2202 and 2252. For example, encoder 2204 and decoder 2254 can be coupled to the same one or more interfaces to receive data and control information or input bits used by the encoder for encoding, and output the recovered data and control information decoded by the decoder from the received encoded bits. Encoder 2204 and decoder 2254 can also, or alternatively, be coupled to the same one or more interfaces to output encoded bits generated by the encoder and receive encoded bits used by the decoder for decoding.

[0387] In one embodiment, an apparatus includes a decoder (e.g., decoder 2254) for decoding recovered data and bits associated with control information from received coded bits. An interface 2256 is coupled to the decoder for receiving the coded bits disclosed herein. An apparatus may also include an interface (e.g., output interface 2252 in some embodiments) for outputting the recovered data bits and bits associated with control information. More generally, an apparatus or a component thereof (e.g., decoder 2254 or a processor) may be used to decode coded bits; or a program may include instructions for decoding coded bits. An apparatus or a component thereof (e.g., interface 2256 coupled to decoder 2254) may be used to receive or otherwise acquire codewords; or a program may include instructions for receiving or otherwise acquiring codewords, or instructions for causing a processor to receive or otherwise acquire codewords. Receiving may include receiving coded bits from a first communication device via a second communication device in a wireless communication network.

[0388] As in the examples described in at least the further detailed above, the encoded bits are generated by jointly encoding the input bits, which include data bits and bits associated with control information. The input bits have been jointly encoded according to a first code, which differs from a second code, and the second encoded bits are generated from the control information based on this second code.

[0389] Embodiments associated with such devices or non-transitory computer-readable storage media may include any one or more of the following features, which have also been discussed elsewhere herein:

[0390] The bits associated with the control information may be or include second coded bits generated from the control information;

[0391] The first code can be an LDPC code;

[0392] The second code can be a polar code;

[0393] The device or its components (e.g., decoder 2254, interface 2256, or receiver coupled to interface 2256) may be used to receive the second coded bit; or the program may include instructions for receiving the second coded bit, or instructions for causing the processor to receive the second coded bit;

[0394] The device or its components (e.g., decoder 2254) may be used to decode control information recovered from the received second coded bits; or the program may include instructions for decoding control information recovered from the received second coded bits, or instructions for causing the processor to decode control information recovered from the received second coded bits.

[0395] The device or its components (e.g., decoder 2254) may be used to decode received coded bits based on control information recovered from the received second coded bits; or the program may include instructions for decoding received coded bits based on control information recovered from the received second coded bits, or instructions for causing the processor to decode received coded bits based on control information recovered from the received second coded bits.

[0396] The device or its components (e.g., decoder 2254, interface 2256, or receiver coupled to interface 2256) may be used to receive additional encoded bits generated by encoding other control information; or the program may include instructions for receiving additional encoded bits generated by encoding other control information, or instructions for causing the processor to receive additional encoded bits generated by encoding other control information.

[0397] The device or its components (e.g., decoder 2254) may be used to decode other control information recovered from other received coded bits; or the program may include instructions for decoding other control information recovered from other received coded bits, or instructions for causing the processor to decode other control information recovered from other received coded bits.

[0398] Other encoded bits can be generated by encoding other control information according to the second code or other codes having the same (or different) code type as the second code;

[0399] Other control information may be of the same (or different) type as the control information;

[0400] Other control information can have a different priority than control information;

[0401] Other control information may include control information and additional control information;

[0402] Other coded bits can be generated by jointly encoding control information and additional control information;

[0403] The second coded bit may be or include a subset of coded bits from the set of coded bits generated by encoding control information;

[0404] The set of encoded bits may include second encoded bits and additional encoded bits;

[0405] The second coded bit may include one or more bits selected from the set based on rate matching applied to the set of coded bits;

[0406] In the case of rate matching including puncturing, one or more bits may have been selected from the punctured bits in the set of coded bits;

[0407] In cases where rate matching includes shortening, one or more bits may have been selected from the shortened bits in the set of coded bits;

[0408] In cases where rate matching includes repetition, one or more bits may have been selected from bits other than the repetitive bits in the coded bit set;

[0409] The device or its components (e.g., decoder 2254, interface 2256, or receiver coupled to interface 2256) may be used to receive coded bits in a data channel; or the program may include instructions for receiving coded bits in a data channel, or instructions for causing the processor to receive coded bits in a data channel.

[0410] The device or its components (e.g., decoder 2254, interface 2256, or receiver coupled to interface 2256) may be used to receive a second coded bit in a data channel; or the program may include instructions for receiving a second coded bit in a data channel, or instructions for causing the processor to receive a second coded bit in a data channel.

[0411] The data channel can be PUSCH;

[0412] Data bits may include or include upstream data;

[0413] Control information may include or include uplink control information (UCI).

[0414] Other features disclosed herein may also be provided or supported in device embodiments, either in addition to those disclosed herein.

[0415] The device embodiments are not limited in any way to a single device. For example, a system may include a first communication device and a second communication device. The first communication device may be used to: encode input bits to generate encoded bits and transmit the encoded bits; the second communication device may be used to receive and decode the encoded bits. The input bits may include data bits and bits associated with control information. The input bits are encoded by jointly encoding the data bits and the bits associated with control information, which includes jointly encoding the data bits and the bits associated with control information according to a first code. The first code is different from a second code, and the second encoded bits are generated from the control information according to the second code.

[0416] More generally, other features disclosed herein may also be provided in the method, apparatus and / or system embodiments.

[0417] Some aspects of this disclosure can achieve the following benefits:

[0418] • Enhance UCI reliability without requiring additional UCI duplication.

[0419] • Minimize the impact on PUSCH

[0420] • UCI can still be decoded first to minimize latency.

[0421] • Polar code rate matching schemes help improve performance

[0422] • Compatible with or easily describable standard definitions for UCI UL-SCH reuse

[0423] Since only the polar codes are hard-decoded, the decoding complexity does not increase significantly.

[0424] This disclosure includes various embodiments, not only method embodiments but also other embodiments, such as apparatus embodiments and embodiments related to non-transitory computer-readable storage media. Embodiments may be incorporated individually or in combination with the features disclosed herein.

[0425] Although this disclosure references illustrative embodiments, it is not intended to be interpreted in a limiting sense. Various modifications and combinations of the illustrative embodiments, as well as other embodiments of this disclosure, will be apparent to those skilled in the art upon reference to this specification.

[0426] For example, this document primarily describes embodiments within the context of uplink data and control information. However, the features disclosed herein can also be applied, or alternatively, to the downlink, where data and control information may include downlink data and DCI, etc. Other scenarios are also possible.

[0427] Additionally or alternatively, features disclosed herein in the context of any particular embodiment may be implemented in other embodiments. For example, method embodiments may be implemented in apparatus, system, and / or computer program product embodiments. Furthermore, although embodiments are described primarily in the context of methods and apparatus, other implementations are contemplated as instructions stored in non-transitory computer-readable media, etc. Such media may store programs or instructions to perform any of the methods consistent with this disclosure.

[0428] Therefore, the description and drawings are to be considered merely as illustrations of some embodiments of the present disclosure as defined in the appended claims, and are intended to cover any and all modifications, variations, combinations, or equivalents falling within the scope of the present disclosure. Thus, although the present disclosure and its advantages have been described in detail, various changes, substitutions, and alterations may be made herein without departing from the present disclosure as defined in the appended claims. Furthermore, the scope of this application is not limited to the specific embodiments of the processes, machines, articles of manufacture, material compositions, apparatuses, methods, and steps described in the specification. It will be readily understood by those skilled in the art from the disclosure of this document that processes, machines, articles of manufacture, material compositions, modules, methods, or steps that exist now or will be developed later, performing substantially the same function as the corresponding embodiments described herein or achieving substantially the same results as the corresponding embodiments described herein, can be used in accordance with this disclosure. Accordingly, the scope of the appended claims is intended to include such processes, machines, articles of manufacture, material compositions, components, methods, or steps.

[0429] Furthermore, any module, component, or device executing instructions illustrated herein may include or otherwise access a non-transitory computer-readable or processor-readable storage medium to store information such as computer-readable or processor-readable instructions, data structures, program modules, and / or other data. A non-exhaustive list of examples of non-transitory computer-readable or processor-readable storage media includes magnetic tape cassettes, magnetic tape, disk storage or other magnetic storage devices, compact disc read-only memory (CD-ROM), digital video disc or digital versatile disc (DVD), Blu-ray™ and other optical discs, volatile and non-volatile, removable and non-removable media implemented in any method or technology, random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other storage technologies. Any such non-transitory computer-readable or processor-readable storage medium may be part of a device, or may be accessible to or connected to that device. Any application or module described herein may be implemented using computer-readable and executable instructions, or may be stored and held by such non-transitory computer-readable or processor-readable storage media.

[0430] This article may use the following abbreviations, acronyms, and acronyms:

[0431]

[0432]

Claims

1. A method, characterized in that, include: The input bits are encoded to generate encoded bits, wherein the input bits include data bits and bits associated with control information, the encoding includes jointly encoding the data bits and the bits associated with the control information, and jointly encoding the data bits and the bits associated with the control information includes jointly encoding the data bits and the bits associated with the control information according to a first code, wherein the first code is different from a second code, and the second encoded bits are generated from the control information according to the second code; Output the encoded bits.

2. The method according to claim 1, characterized in that, The bits associated with the control information include the second encoded bits generated from the control information.

3. The method according to claim 1 or 2, characterized in that, The first code is a low-density parity-check (LDPC) code, and the second code is a polar code.

4. The method according to any one of claims 1 to 3, characterized in that, Also includes: The control information is encoded according to the second code to generate the second encoded bits; Output the second encoded bit.

5. The method according to any one of claims 1 to 4, characterized in that, Also includes: Encode other control information to generate other encoded bits; Output the other encoded bits.

6. The method according to claim 5, characterized in that, Encoding the other control information includes encoding the other control information according to other codes having the same code type as the second code.

7. The method according to claim 5 or 6, characterized in that, The other control information has the same type as the control information, but has a different priority.

8. The method according to any one of claims 5 to 7, characterized in that, The other control information includes the control information and additional control information; encoding the other control information includes jointly encoding the control information and the additional control information.

9. The method according to any one of claims 1 to 8, characterized in that, The second coded bits include a subset of coded bits selected from a set of coded bits generated by encoding the control information, the set of coded bits including the second coded bits and additional coded bits.

10. The method according to claim 9, characterized in that, Also includes: Rate matching is applied to the set of coded bits, wherein, The second encoded bit includes one or more bits selected from the set based on the rate matching.

11. The method according to any one of claims 1 to 10, characterized in that, Also includes: The encoded bits are transmitted in the data channel, and the second encoded bits are also transmitted.

12. The method according to any one of claims 1 to 11, characterized in that, Also includes: The transport block size is determined based on the allocated resources; The payload size of the data bits is determined based on the transport block size, wherein, The transport block size is determined taking into account the resources allocated to the control information, or the payload size is determined based on the bits associated with the control information.

13. The method according to any one of claims 1 to 12, characterized in that, Also includes: Map the encoded symbols of the second encoded bits to resources used for transmitting the control information; After mapping the encoded symbols of the second encoded bits, the encoded symbols of the encoded bits are mapped to resources used for transmitting data.

14. The method according to claim 13, characterized in that, The second encoded bit and the encoded bit include the bit associated with the control information; The encoded symbols that map the encoded bits include encoded symbols that map only the encoded bits other than those associated with the control information.

15. The method according to any one of claims 11 to 14, characterized in that, The resources include Physical Uplink Shared Channel (PUSCH) resources.

16. The method according to any one of claims 1 to 15, characterized in that, The data bits include uplink data, and the control information includes uplink control information (UCI).

17. A method, characterized in that, include: Receive coded bits generated by jointly encoding input bits, wherein the input bits include data bits and bits associated with control information, the input bits have been jointly encoded according to a first code, which is different from a second code, and the second coded bits are generated from the control information according to the second code; The output recovers the data bits and the bits associated with the control information decoded from the received encoded bits.

18. The method according to claim 17, characterized in that, The bits associated with the control information include the second encoded bits generated from the control information.

19. The method according to claim 17 or 18, characterized in that, The first code is a low-density parity-check (LDPC) code, and the second code is a polar code.

20. The method according to any one of claims 17 to 19, characterized in that, Also includes: Receive the second encoded bits; Output the recovered control information obtained by decoding the received second encoded bits.

21. The method according to claim 20, characterized in that, Also includes: The received coded bits are decoded based on the recovered control information obtained from decoding the received second coded bits.

22. The method according to any one of claims 17 to 21, characterized in that, Also includes: Receive other encoded bits generated by encoding other control information; Output the recovered control information obtained by decoding the other coded bits received.

23. The method according to claim 22, characterized in that, The other encoded bits have been generated by encoding the other control information according to other codes having the same code type as the second code.

24. The method according to claim 22 or 23, characterized in that, The other control information has the same type as the control information, but has a different priority.

25. The method according to any one of claims 22 to 24, characterized in that, The other control information includes the control information and additional control information; The other coded bits were generated by jointly encoding the control information and the additional control information.

26. The method according to any one of claims 17 to 25, characterized in that, The second coded bit includes a subset of coded bits from a set of coded bits generated by encoding the control information, the set of coded bits including the second coded bit and additional coded bits.

27. The method according to claim 26, characterized in that, The second coded bit includes one or more bits selected from the set based on rate matching applied to the set of coded bits.

28. The method according to any one of claims 17 to 27, characterized in that, Receiving the encoded bits includes receiving the encoded bits in a data channel; The method further includes: The second encoded bit is received in the data channel.

29. The method according to claim 28, characterized in that, The data channel is the Physical Uplink Shared Channel (PUSCH).

30. The method according to any one of claims 17 to 29, characterized in that, The data bits include uplink data, and the control information includes uplink control information (UCI).

31. An apparatus, characterized in that, Includes a processor for causing the device to perform the method according to any one of claims 1 to 16.

32. An apparatus, characterized in that, include: An encoder is used to encode input bits to generate coded bits, wherein the input bits include data bits and bits associated with control information, the encoding includes jointly encoding the data bits and the bits associated with the control information, and jointly encoding the data bits and the bits associated with the control information includes jointly encoding the data bits and the bits associated with the control information according to a first code, the first code being different from a second code, and the second coded bits being generated from the control information according to the second code; An interface, coupled to the encoder, is used to output the encoded bits.

33. The apparatus according to claim 32, characterized in that, The bits associated with the control information include the second encoded bits generated from the control information.

34. The apparatus according to claim 32 or 33, characterized in that, The first code is a low-density parity-check (LDPC) code, and the second code is a polar code.

35. The apparatus according to any one of claims 32 to 34, characterized in that, The encoder is further configured to encode the control information according to the second code to generate the second encoded bits; The interface is also used to output the second encoded bits.

36. The apparatus according to any one of claims 32 to 35, characterized in that, The encoder is also used to encode other control information to generate other encoded bits; The interface is also used to output the other encoded bits.

37. The apparatus according to claim 36, characterized in that, The encoder is used to encode the other control information according to other codes that have the same code type as the second code.

38. The apparatus according to claim 36 or 37, characterized in that, The other control information has the same type as the control information, but has a different priority.

39. The apparatus according to any one of claims 36 to 38, characterized in that, The other control information includes the control information and additional control information; The encoder is used to jointly encode the control information and the additional control information.

40. The apparatus according to any one of claims 32 to 39, characterized in that, The second coded bits include a subset of coded bits selected from a set of coded bits generated by encoding the control information, the set of coded bits including the second coded bits and additional coded bits.

41. The apparatus according to claim 40, characterized in that, Also includes: A rate matching module, coupled to the interface, is used to apply rate matching to the set of coded bits; The second encoded bit includes one or more bits selected from the set based on the rate matching.

42. The apparatus according to any one of claims 32 to 41, characterized in that, Also includes: A transmitter, coupled to the interface, is used to transmit the coded bits and the second coded bits in a data channel.

43. The apparatus according to any one of claims 32 to 41, characterized in that, Also includes: A transmitter, coupled to the interface, is configured to: determine a transport block size based on allocated resources, and determine the payload size of the data bits based on the transport block size; The transport block size is determined taking into account the resources allocated to the control information, or the payload size is determined based on the bits associated with the control information.

44. The apparatus according to any one of claims 32 to 41, characterized in that, Also includes: A transmitter, coupled to the interface, is configured to: map the encoded symbols of the second encoded bits to resources for transmitting the control information, and, after mapping the encoded symbols of the second encoded bits, map the encoded symbols of the encoded bits to resources for transmitting data.

45. The apparatus according to claim 44, characterized in that, The second encoded bit and the encoded bit include the bit associated with the control information; The transmitter is configured to: map the encoded symbols of the encoded bits by mapping only the encoded symbols of the encoded bits other than the bits associated with the control information.

46. ​​The apparatus according to any one of claims 42 to 45, characterized in that, The resources include Physical Uplink Shared Channel (PUSCH) resources.

47. The apparatus according to any one of claims 32 to 46, characterized in that, The data bits include uplink data, and the control information includes uplink control information (UCI).

48. An apparatus, characterized in that, Includes a processor for causing the device to perform the method according to any one of claims 17 to 30.

49. An apparatus, characterized in that, include: An interface for receiving encoded bits generated by jointly encoding input bits, wherein the input bits include data bits and bits associated with control information, the input bits being jointly encoded according to a first code, which is different from a second code, and the second encoded bits being generated from the control information according to the second code; A decoder, coupled to the interface, is used to decode recovered data bits and the bits associated with the control information from the received encoded bits.

50. The apparatus according to claim 49, characterized in that, The bits associated with the control information include the second encoded bits generated from the control information.

51. The apparatus according to claim 49 or 50, characterized in that, The first code is a low-density parity-check (LDPC) code, and the second code is a polar code.

52. The apparatus according to any one of claims 49 to 51, characterized in that, The interface is also used to receive the second encoded bits; The decoder is also used to decode the recovered control information from the received second encoded bits.

53. The apparatus according to claim 52, characterized in that, The decoder is further configured to: decode the received coded bits based on the recovered control information obtained from decoding the received second coded bits.

54. The apparatus according to any one of claims 49 to 53, characterized in that, The interface is also used to receive other encoded bits generated by encoding other control information; The decoder is also used to decode and recover other control information from the other coded bits received.

55. The apparatus according to claim 54, characterized in that, The other encoded bits have been generated by encoding the other control information according to other codes having the same code type as the second code.

56. The apparatus according to claim 54 or 55, characterized in that, The other control information has the same type as the control information, but has a different priority.

57. The apparatus according to any one of claims 54 to 56, characterized in that, The other control information includes the control information and additional control information; The other coded bits were generated by jointly encoding the control information and the additional control information.

58. The apparatus according to any one of claims 49 to 57, characterized in that, The second coded bit includes a subset of coded bits from a set of coded bits generated by encoding the control information, the set of coded bits including the second coded bit and additional coded bits.

59. The apparatus according to claim 58, characterized in that, The second coded bit includes one or more bits selected from the set based on rate matching applied to the set of coded bits.

60. The apparatus according to any one of claims 49 to 59, characterized in that, The interface is used to receive the encoded bits in the data channel; The interface is also used to receive the second encoded bits in the data channel.

61. The apparatus according to claim 60, characterized in that, The data channel is the Physical Uplink Shared Channel (PUSCH).

62. The apparatus according to any one of claims 49 to 61, characterized in that, The data bits include uplink data, and the control information includes uplink control information (UCI).

63. A computer program, characterized in that, Includes a program for execution by a processor, the program including instructions for performing the method according to any one of claims 1 to 30.

64. A non-transitory computer-readable medium, characterized in that, The program is stored for execution by a processor, the program including instructions for performing the method according to any one of claims 1 to 30.

65. A system, characterized in that, include: A first communication device is configured to: encode input bits to generate encoded bits, and transmit the encoded bits; The input bits include data bits and bits associated with control information; The input bits are encoded by jointly encoding the data bits and the bits associated with the control information. Joint encoding of the data bits and the bits associated with the control information includes jointly encoding the data bits and the bits associated with the control information according to a first code, wherein the first code is different from a second code, and the second encoded bits are generated from the control information according to the second code. The system also includes: A second communication device is used to receive and decode the encoded bits.

Images