Method and apparatus for performing channel coding and decoding in wireless communication system

Abstract

The present disclosure relates to a 5G communication system or a 6G communication system for supporting higher data rates beyond a 4G communication system such as long term evolution (LTE). A method (500) for channel coding performed at a transmitter (202) includes applying a pre-processing operation on a coding scheme based on a plurality of parameters such as code rate, code length, information length, data type, equipmemt type, service type, resource allocation parameters, number of time domain symbols, etc. Further, the method (500) includes encoding data to be transmitted based on the pre-processed coding scheme and transmitting, to a receiver via a plurality of transmission channels, the encoded data along with one of an indication of the coding scheme or the application of the pre-processing operation on the coding scheme.

Description

METHOD AND APPARATUS FOR PERFORMING CHANNEL CODING AND DECODING IN WIRELESS COMMUNICATION SYSTEM

[0001] The present disclosure relates to channel coding in wireless communication systems, and more particularly relates to a method for performing a channel coding and decoding at a transmitter and a receiver, respectively.

[0002] Considering the development of wireless communication from generation to generation, the technologies have been developed mainly for services targeting humans, such as voice calls, multimedia services, and data services. Following the commercialization of 5G (5th-generation) communication systems, it is expected that the number of connected devices will exponentially grow. Increasingly, these will be connected to communication networks. Examples of connected things may include vehicles, robots, drones, home appliances, displays, smart sensors connected to various infrastructures, construction machines, and factory equipment. Mobile devices are expected to evolve in various form-factors, such as augmented reality glasses, virtual reality headsets, and hologram devices. In order to provide various services by connecting hundreds of billions of devices and things in the 6G (6th-generation) era, there have been ongoing efforts to develop improved 6G communication systems. For these reasons, 6G communication systems are referred to as beyond-5G systems.

[0003] 6G communication systems, which are expected to be commercialized around 2030, will have a peak data rate of tera (1,000 giga)-level bps and a radio latency less than 100μsec, and thus will be 50 times as fast as 5G communication systems and have the 1 / 10 radio latency thereof.

[0004] In order to accomplish such a high data rate and an ultra-low latency, it has been considered to implement 6G communication systems in a terahertz band (for example, 95GHz to 3THz bands). It is expected that, due to severer path loss and atmospheric absorption in the terahertz bands than those in mmWave bands introduced in 5G, technologies capable of securing the signal transmission distance (that is, coverage) will become more crucial. It is necessary to develop, as major technologies for securing the coverage, radio frequency (RF) elements, antennas, novel waveforms having a better coverage than orthogonal frequency division multiplexing (OFDM), beamforming and massive multiple input multiple output (MIMO), full dimensional MIMO (FD-MIMO), array antennas, and multiantenna transmission technologies such as large-scale antennas. In addition, there has been ongoing discussion on new technologies for improving the coverage of terahertz-band signals, such as metamaterial-based lenses and antennas, orbital angular momentum (OAM), and reconfigurable intelligent surface (RIS).

[0005] Moreover, in order to improve the spectral efficiency and the overall network performances, the following technologies have been developed for 6G communication systems: a full-duplex technology for enabling an uplink transmission and a downlink transmission to simultaneously use the same frequency resource at the same time; a network technology for utilizing satellites, high-altitude platform stations (HAPS), and the like in an integrated manner; an improved network structure for supporting mobile base stations and the like and enabling network operation optimization and automation and the like; a dynamic spectrum sharing technology via collison avoidance based on a prediction of spectrum usage; an use of artificial intelligence (AI) in wireless communication for improvement of overall network operation by utilizing AI from a designing phase for developing 6G and internalizing end-to-end AI support functions; and a next-generation distributed computing technology for overcoming the limit of UE computing ability through reachable super-high-performance communication and computing resources (such as mobile edge computing (MEC), clouds, and the like) over the network. In addition, through designing new protocols to be used in 6G communication systems, developing mecahnisms for implementing a hardware-based security environment and safe use of data, and developing technologies for maintaining privacy, attempts to strengthen the connectivity between devices, optimize the network, promote softwarization of network entities, and increase the openness of wireless communications are continuing.

[0006] It is expected that research and development of 6G communication systems in hyper-connectivity, including person to machine (P2M) as well as machine to machine (M2M), will allow the next hyper-connected experience. Particularly, it is expected that services such as truly immersive extended reality (XR), high-fidelity mobile hologram, and digital replica could be provided through 6G communication systems. In addition, services such as remote surgery for security and reliability enhancement, industrial automation, and emergency response will be provided through the 6G communication system such that the technologies could be applied in various fields such as industry, medical care, automobiles, and home appliances.

[0007] The development of entirely new channel coding schemes to address existed limitations may risk incompatibility with existing 5G infrastructure. Accordingly, there exists a need for techniques that enhance the performance of existing coding schemes to meet 6G KPIs, while preserving backward compatibility with 5G systems.

[0008] Amethod (500) for channel coding performed at a transmitter (202) includes applying a pre-processing operation on a coding scheme based on a plurality of parameters such as code rate, code length, information length, data type, equipmemt type, service type, resource allocation parameters, number of time domain symbols, etc. Further, the method (500) includes encoding data to be transmitted based on the pre-processed coding scheme and transmitting, to a receiver via a plurality of transmission channels, the encoded data along with one of an indication of the coding scheme or the application of the pre-processing operation on the coding scheme.

[0009] The foregoing and other features of embodiments will become more apparent from the following detailed description of embodiments when read in conjunction with the accompanying drawings. In the drawings, like reference numerals refer to like elements.

[0010] Figure 1A illustrates a block diagram for a channel encoder, in accordance with existing techniques;

[0011] Figure 1B illustrates a block diagram for a channel decoder, in accordance with existing techniques;

[0012] Figure 1C illustrates a block diagram of Polarization Adjusted Convolutional (PAC) codes, with pre-processing and post-processing convolutional blocks, in accordance with existing techniques;

[0013] Figure 1D illustrates Polarization Adjusted Convolutional (PAC) codes, in accordance with existing technique;

[0014] Figure 2 illustrates an environment depicting a transmitter and a receiver for establishing channel coding and channel decoding, in accordance with an embodiment of the present disclosure;

[0015] Figure 3 illustrates an exemplary environment including systems for performing the channel coding and channel decoding, respectively, in accordance with an embodiment of the present disclosure;

[0016] Figure 4A illustrates a flowchart of steps performed by the system to perform the channel coding, in accordance with an embodiment of the present disclosure;

[0017] Figure 4B illustrates a block diagram for the identification of the coding scheme by the transmitter, in accordance with an embodiment of the present disclosure;

[0018] Figure 4C illustrates an operation performed by the system to perform the channel decoding, in accordance with an embodiment of the present disclosure;

[0019] Figure 5 illustrates a flowchart for a method performed by the system to perform the channel coding, in accordance with an embodiment of the present disclosure; and

[0020] Figure 6 illustrates a flowchart for a method performed by the system to perform the channel decoding, in accordance with an embodiment of the present disclosure;

[0021] This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the disclosure. This summary is neither intended to identify key or essential inventive concepts of the disclosure nor is it intended for determining the scope of the disclosure.

[0022] According to an embodiment of the present disclosure, a method for channel coding performed at a transmitter is disclosed. The method includes applying a pre-processing operation on a coding scheme based on a plurality of parameters. The pre-processing operation includes one or more of a rate-k pre-transform operation, a rate-k post-transform operation, a pre-coding operation, an outer code application, or an inner code application. Further, the method includes encoding data to be transmitted based on the pre-processed coding scheme. The transmission data includes at least one of user data or control data. Furthermore, the method includes transmitting, to a receiver via a plurality of transmission channels, the encoded data along with one of an indication of the coding scheme or the application of the pre-processing operation on the coding scheme.

[0023] In another embodiment, a method for channel decoding performed at a receiver is disclosed. The method includes receiving, from a transmitter via a plurality of transmission channels, an encoded data along with one of an indication of a coding scheme or application of a pre-processing operation on the coding scheme. Further, the method includes decoding the received encoded data based on applying a post-processing operation to the coding scheme. The post-processing operation includes a reverse operation of one or more of a rate-k pre-transform operation, a rate-k post-transform operation, a pre-coding operation, an outer code application, or an inner code application.

[0024] In yet another embodiment, a system at a transmitter for channel coding. The system is configured to apply a pre-processing operation on a coding scheme based on a plurality of parameters. The pre-processing operation includes one or more of a rate-k pre-transform operation, a rate-k post-transform operation, a pre-coding operation, an outer code application, or an inner code application. Further, the system is configured to encode data to be transmitted based on the pre-processed coding scheme. The transmission data includes at least one of user data or control data. Furthermore, the system is configured to transmit, to a receiver via a plurality of transmission channels, the encoded data along with one of an indication of the coding scheme or the application of the pre-processing operation on the coding scheme.

[0025] In yet another embodiment, a system at a receiver for channel decoding, is disclosed. The system is configured to receive, from a transmitter via a plurality of transmission channels, an encoded data along with one of an indication of a coding scheme or application of a pre-processing operation on the coding scheme. The system is configured to decode the received encoded data based on applying a post-processing operation to the coding scheme. The post-processing operation includes a reverse operation of one or more of a rate-k pre-transform operation, a rate-k post-transform operation, a pre-coding operation, an outer code application, or an inner code application.

[0026] To further clarify the advantages and features of the present disclosure, a more particular description will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawing. It is appreciated that these drawings depict only typical embodiments and are therefore not to be considered limiting its scope. The embodiments will be described and explained with additional specificity and detail with the accompanying drawings.

[0027] For the purpose of promoting an understanding of the principles of the present disclosure, reference will now be made to the various embodiments and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the present disclosure is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the present disclosure as illustrated therein being contemplated as would normally occur to one skilled in the art to which the present disclosure relates.

[0028] It will be understood by those skilled in the art that the foregoing general description and the following detailed description are explanatory of the present disclosure and are not intended to be restrictive thereof.

[0029] Whether or not a certain feature or element was limited to being used only once, it may still be referred to as "one or more features" or "one or more elements" or "at least one feature" or "at least one element." Furthermore, the use of the terms "one or more" or "at least one" feature or element do not preclude there being none of that feature or element, unless otherwise specified by limiting language including, but not limited to, "there needs to be one or more ..." or "one or more elements is required."

[0030] Reference is made herein to some "embodiments." It should be understood that an embodiment is an example of a possible implementation of any features and / or elements of the present disclosure. Some embodiments have been described for the purpose of explaining one or more of the potential ways in which the specific features and / or elements of the proposed disclosure fulfil the requirements of uniqueness, utility, and non-obviousness.

[0031] Use of the phrases and / or terms including, but not limited to, "a first embodiment," "a further embodiment," "an alternate embodiment," "one embodiment," "an embodiment," "multiple embodiments," "some embodiments," "other embodiments," "further embodiment", "furthermore embodiment", "additional embodiment" or other variants thereof do not necessarily refer to the same embodiments. Unless otherwise specified, one or more particular features and / or elements described in connection with one or more embodiments may be found in one embodiment, or may be found in more than one embodiment, or may be found in all embodiments, or may be found in no embodiments. Although one or more features and / or elements may be described herein in the context of only a single embodiment, or in the context of more than one embodiment, or in the context of all embodiments, the features and / or elements may instead be provided separately or in any appropriate combination or not at all. Conversely, any features and / or elements described in the context of separate embodiments may alternatively be realized as existing together in the context of a single embodiment.

[0032] Any particular and all details set forth herein are used in the context of some embodiments and therefore should not necessarily be taken as limiting factors to the proposed disclosure.

[0033] The terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such process or method. Similarly, one or more devices or sub-systems or elements or structures or components proceeded by "comprises... a" does not, without more constraints, preclude the existence of other devices or other sub-systems or other elements or other structures or other components or additional devices or additional sub-systems or additional elements or additional structures or additional components.

[0034] Figure 1A illustrates a block diagram for a channel encoder, in accordance with existing techniques. Figure 1B illustrates a block diagram for a channel decoder, in accordance with existing techniques. Figure 1C illustrates a block diagram of Polarization Adjusted Convolutional (PAC) codes, with pre-processing and post-processing convolutional blocks, in accordance with existing techniques. Figure 1D illustrates Polarization Adjusted Convolutional (PAC) codes, in accordance with existing technique. Figures 1a to 1d are explained in conjunction for the sake of brevity. Channel encoding is a method used to minimize errors in data transmission over unreliable or noisy communication channels by adding extra bits, known as redundancy, to the original data. The channel encoder is defined as: (N,K), where N is the length of the encoded output and K is the length of the input information bits, resulting in an encoding rate = K / N. Herein, the channel encoder receives code block bits and cyclic redundancy checks (Length K) associated with the information bits. Thereafter, the channel encoder processes the code block bits and the cyclic redundancy checks (length k) and generates an output as an encoded code block having length N. Further, the channel decoder is used to decode encoded bits or the encoded code block into the information bits. Further, in real-time systems, a receiver may obtain Log Likelihood Ratios (LLRs) for the encoded bits, which indicate the probability of each bit being 0 or 1. The channel decoder utilizes these LLRs to decode the data and generate hard output bits, representing final decisions on the bit values.

[0035] The channel encoding in Near Radio (NR) may be differentiated between polar encoding andLow-Density Parity-Check (LDPC)encoding. The polar encoding is used for control and broadcast channels, that is, including downlink control information (DCI) via physical downlink control channel (PDCCH), master information block (MIB) via physical broadcast channel (PBCH), and uplink control information (UCI) via physical uplink control channel (PUCCH) / physical uplink shared channel (PUSCH). Table-1 illustrates the usage of the channel coding scheme for transport channels (TrCHs).

[0036]

[0037] Table-1

[0038] Further, the LDPC encoding is an error-correcting technique used to enhance the reliability of data transmission over noisy communication channels. The LDPC encoding is used for data channels, including the PDSCH and the PUSCH. Table-2 illustrates the usage of the channel coding scheme for control information.

[0039]

[0040] Table-2

[0041] Further, polar codes are a class of error-correcting codes that achieve the capacity of symmetric binary-input discrete memoryless channels. The polar codes are capacity achieving codes that were based on the concept of channel polarization. Specifically, in polar codes, each bit is made to be transmitted either via a noiseless channel or an extremely noisy channel. Further, the polarization is achieved through a polar transform. The polar codes are accepted by third generation partnership project (3GPP) and are being used for control and broadcast data transmissions in fifth generation (5G) new radio (NR), including downlink control information (DCI) via physical downlink control channel (PDCCH), master information block (MIB) via physical broadcast channel (PBCH), and uplink control information (UCI) via physical uplink control channel (PUCCH) / physical uplink shared channel (PUSCH).

[0042] Furthermore, PAC codes are considered as a channel coding scheme in addition to the polar codes for sixth generation (6G) control channels and the 6G data channels. More specifically, the PAC codes are a variant of polar codes, with an outer-loop extension using convolutional codes, mainly to improve the performance of the polar codes, by increasing a minimum distance between the codewords. The PAC codes are more efficient than the polar codes at all code rates. The PAC codes have more gain specifically at lower code rates, when constructed with 5G-RAM sequence for shorter lengths, and when concatenated with CRC for moderate lengths.

[0043] Further, the implementation of the PAC codes is possible by a convolutional block at the encoder and a de-convolutional block at the receiver. Further, the encoder and the de-convolutional block are compatible with existing 5G NR control Tx-Rx chain, with pre-processing and post-processing blocks at the transmitter and receiver, respectively, as shown in Figure 1C. Herein, rate profiling involves applying a reliability sequence to the information bit stream to generate information bits and frozen bits. These bits are then processed through a convolutional transform, where convolutional encoding is applied to generate convolutionally encoded bits. Following this, a polar encoding is performed using a Kronecker product on the convolutionally encoded bits. For decoding, a method, for example, successive cancellation combined with trellis search is employed, for decoding PAC codes. Finally, information bit extraction is carried out, where the decoder's output codeword is used along with the reliability sequence to retrieve the original information bits. For the 6G wireless communication networks, a combination of polar codes and PAC codes is studied, for consideration in both control channel extensions for larger control lengths, and also for small codeword lengths within data channels.

[0044] The polar codes and implementation of compatible variants, such as the PAC codes, play an important role in the upcoming 6G systems. 6G control and data channels are being considered for achieving higher code rates and codeword lengths. Further, integrating the PAC codes into 6G is compatible with existing fifth generation (5G) standards. Moreover, there may be a chance of selection of the coding scheme, given the signal strength conditions at the receiver (base station (BS) or user equipment (UE)).

[0045] Particularly, the polar codes are extended to the data channels for smaller block lengths, when the LDPC codes underperform for small block lengths or small payload lengths due to structural weakness in the data channels.

[0046] Thus,the PAC codes are added for the control channels to support a larger code length of control data, and to the data channels with small block lengths and smaller code rates, as shwown in Figure 1D.

[0047] Hence, there is a need to define the protocol to integrate the polar codes, pre-transformed polar codes, and the variants such as the PAC codes in the next generation systems beyond the 5G and the 6G.

[0048] Additionally, the control channel in 5G (specifically PUCCH or PUSCH for uplink) carries Uplink Control Information (UCI), such as Channel state information (CSI), Scheduling requests (SR), and Hybrid-ARQ acknowledgements (HARQ-ACK). Herein, the UCI must be encoded reliably, especially under poor channel conditions, which is where error-correcting codes like polar codes come in. However, currently, polar codes used for UCI on the control channel are limited to a maximum codeword length of 1024 bits. Thereafter, the polar codes degraded at the length of 1024 but for small code rates. To handle longer UCI payloads (up to 1706 bits), Code Block Segmentation (CB Segmentation) is used. This means the payload is split into two smaller blocks, each encoded separately with polar codes. However, only 2 CBs are supported, which limits the total payload to ~2000 bits.

[0049] Thus, as would be gathered, in current 5G communication systems, channel coding schemes such as Low-Density Parity-Check (LDPC) codes and polar codes are employed for data and control channels, respectively. However, these existing coding schemes exhibit limitations in meeting the stringent Key Performance Indicators (KPIs) anticipated for 6th Generation (6G) and future communication systems. In particular, performance degradation is observed in scenarios involving short data lengths and extended control information lengths. For instance, while polar codes serve as the coding solution for 5G New Radio (NR) control channels and LDPC codes are utilized for 5G NR data channels, these codes are insufficient to satisfy the 6G requirements in terms of block error rate (BLER) and throughput under certain conditions, specifically, for long control message lengths in the case of polar codes and short data payloads in the case of LDPC codes.

[0050] The development of entirely new channel coding schemes to address these limitations may risk incompatibility with existing 5G infrastructure. Accordingly, there exists a need for techniques that enhance the performance of existing coding schemes to meet 6G KPIs, while preserving backward compatibility with 5G systems.

[0051] Therefore, in view of the above-mentioned problems, it is advantageous to provide an improved system and method that can overcome the above-mentioned problems and limitations associated with the existing channel coding and channel decoding techniques.

[0052] The next generation communication systems, such as 6thGeneration (G), have higher data rate and throughput Key Performance Indicator (KPI) requirements, while requiring compatibility with the existing 5G. Channel coding plays an important role in meeting the required KPIs of 6G. The existing 5G NR LDPC and polar codes suffer from performance degradation in small data lengths and large control lengths, respectively. Pre-transformed, precoded, or concatenated channel coding blocks help in improving a system's performance with a trade-off in complexity, depending on the coding parameters. Such precoding or pre-transform application on channel coding solves the problem of performance improvement with minimal changes to the existing systems. Further, polarization-adjusted convolutional (PAC) codes, proposed recently as an enhancement to the polar codes, are one such example that may be applied to 5G NR polar codes, where the traditional polar codes fail. The PAC codes are considered to be a part of 6G channel coding schemes, for control channel and data channels with lower code rates. Thus, a system and method for integrating these pre-transformed codes such as PAC codes, into 6G systems, is proposed for maintaining compatibility with 5G systems, depending on various coding parameters.

[0053] The system and method as disclosed solve the problem of extending the 5G NR channel coding schemes to the next generation communication systems such as 6G, while maintaining compatibility with 5G. The system and method cover all the options to switch between multiple coding schemes and apply a pre-transform or precoder or concatenation to an existing channel coding scheme, to improve the performance of the system, based on multiple parameters such as codelength, coderate, signal strength, etc. The system and method also cover all the possibilities of signalling required from a transmitter to a receiver and vice versa, to make the concatenated coding feasible in 6G. The example use case of the system and the method is channel coding scheme for control channels such as PDCCH, PUCCH and channel coding scheme for data channels such as PDSCH, PUSCH.

[0054] Embodiments of the present disclosure will be described below in detail with reference to the accompanying drawings.

[0055] For the sake of clarity, the first digit of a reference numeral of each component of the present disclosure is indicative of the Figure number, in which the corresponding component is shown. For example, reference numerals starting with digit "1" are shown at least in Figure 1. Similarly, reference numerals starting with digit "2" are shown at least in Figure 2.

[0056] Figure 2 illustrates an environment 200 depicting a transmitter 202 and a receiver 204 for establishing channel coding and channel decoding, in accordance with an embodiment of the present disclosure.

[0057] In 6G communication systems, channel coding and decoding play a critical role in ensuring ultra-reliable and low-latency transmissions. The channel coding and decoding are performed between the transmitter 202 and the receiver 204 to ensure data integrity and reliability over error-prone channels. The channel coding is performed at the transmitter 202, where redundant bits are added to the original data using techniques, for example, Turbo codes, LDPC (Low-Density Parity-Check) codes, or Polar codes. This redundancy helps protect the data against errors introduced by noise, fading, or interference during transmission. Once the receiver 204 receives the encoded signal, the receiver 204 performs channel decoding to detect and correct any errors without needing retransmission, thereby protecting data from errors resulting in reliable digital communication. Therefore, there is a requirement to perform the channel coding and channel decoding reliably between the transmitter 202 and the receiver 204. In an embodiment, the transmitter 202 may be one of a base station and a User Equipment (UE). Further, the receiver 204 may be one of the UE and the base station, respectively. In an embodiment, the UE may be a smartphone, a tablet, etc., without departing from the scope of the present disclosure. Further, the transmitter 202 may include a system 206, and the receiver 204 may include the system 208, respectively, where the systems 206 and 208 may be configured to perform the channel coding and channel decoding reliably.

[0058] In an embodiment, the system 206 may be deployed within the transmitter 202, without departing from the scope of the present disclosure. In another embodiment, the system 206 may be in communication with the transmitter 202, without departing from the scope of the present disclosure. Similarly, the system 208 may be deployed within the receiver 204, without departing from the scope of the present disclosure. Further, in another embodiment, the system 208 may be configured to be in communication with the receiver 204, without departing from the scope of the present disclosure.

[0059] Further, the constructional details of each of the system 206 and the system 208 may be explained in the subsequent paragraphs in conjunction with Figure 3.

[0060] Figure 3 illustrates an exemplary environment 300 including systems 206 and 208 for performing the channel coding and channel decoding, respectively, in accordance with an embodiment of the present disclosure.

[0061] As shown, the environment 300 may include the system 206 implemented in the transmitter 202. The system 206 is connected to the system 208 corresponding to the receiver 204.

[0062] The system 206 may include at least one processor 302 (hereinafter referred to as the processor 302), a memory 304, one or more modules 306 (referred to herein as the modules), and an interface 316. In an exemplary embodiment, the processor 302 may be in communication with the memory 304, the modules 306, and the interface 316.

[0063] In one embodiment, the processor 302 may include at least one data processor for executing processes in Virtual Storage Area Network. The processor 302 may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc. In one embodiment, the processor 302 may include a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), or both. The processor 302 may be one or more general processors, Digital Signal Processors (DSPs), application-specific integrated circuits, Field-Programmable Gate Arrays (FPGAs), servers, networks, digital circuits, analog circuits, combinations thereof, or other now known or later developed devices for analyzing and processing data. The processor 302 may execute a software program, such as code generated manually (that is, programmed) to perform the desired operation. The processor 302 may implement various techniques such as, but not limited to, image processing, data extraction, Artificial Intelligence (AI), Machine Learning (ML), Deep Learning (DL), and so forth to achieve the desired objective.

[0064] In one embodiment, the processor 302 may be configured to perform the functions of the system 206 and / or the transmitter 202.

[0065] The processor 302 may be disposed in communication with one or more Input / Output (I / O) devices, such as the system 208, via the interface 316. The interface 316 may employ communication Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE), WiMax, or the like, etc.

[0066] In an embodiment, the processor 302 may be disposed in communication with a communication network via a network interface. In an embodiment, the network interface may be the interface 316. The network interface may connect to the communication network to enable connection of the system 206 with the outside environment and / or device / system. The network interface may employ connection protocols including, without limitation, direct connect, Ethernet (e.g., twisted pair 10 / 100 / 1000 Base T), Transmission Control Protocol / Internet Protocol (TCP / IP), token ring, IEEE 802.11 / b / g / n / x, etc. The communication network may include, without limitation, a direct interconnection, Local Area Network (LAN), Wide Area Network (WAN), wireless network (e.g., using Wireless Application Protocol (WAP)), the Internet, etc. Using the network interface and the communication network, the system 206 may communicate with other devices. The network interface may employ connection protocols including, but not limited to, direct connect, Ethernet (e.g., twisted pair 10 / 100 / 1000 Base T), TCP / IP, token ring, IEEE 802.11 / b / g / n / x, etc.

[0067] The memory 304 may be communicatively coupled to the processor 302. The memory 304 may be configured to store data and instructions executable by the processor 302. In one embodiment, the memory 304 may communicate via a bus within the system 206. The memory 304 may include, but is not limited to, a non-transitory computer-readable storage media, such as various types of volatile and non-volatile storage media including, but not limited to, random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, magnetic tape or disk, optical media and the like. In one example, the memory 304 may include a cache or random-access memory for the processor 302. In alternative examples, the memory 304 is separate from the processor 302, such as a cache memory of a processor, the system memory, or other memory. The memory 304 may be an external storage device or database for storing data. The memory 304 may be operable to store instructions executable by the processor 302. The functions, acts, or tasks illustrated in the figures or described may be performed by the programmed processor 302 for executing the instructions stored in the memory 304. The functions, acts, or tasks are independent of the particular type of instruction set, storage media, processor, or processing strategy and may be performed by software, hardware, integrated circuits, firmware, micro-code, and the like, operating alone or in combination. Likewise, processing strategies may include multiprocessing, multitasking, parallel processing, and the like. The memory 304 may further include a database to store the data. Further, the memory 304 may include an operating system for performing one or more tasks of the system 206, as performed by a generic operating system in the communications domain.

[0068] For the sake of brevity, the architecture, and standard operations of the processor 302 and the memory 304 are not discussed in detail. In one embodiment, the memory 304 may be configured to store the information as required by the processor 302 to perform the techniques described herein.

[0069] The modules 306, amongst other things, include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement data types. The modules 306 may also be implemented as, signal processor(s), state machine(s), logic circuitries, and / or any other device or component that manipulates signals based on operational instructions. The modules 306 may be configured to one or more operations of the system 206 and / or the processor 302.

[0070] Further, the modules 306 may be implemented in hardware, instructions executed by a processing unit, or by a combination thereof. The processing unit may comprise a computer, the processor 302, a state machine, a logic array, or any other suitable devices capable of processing instructions. The processing unit may be a general-purpose processor that executes instructions to cause the general-purpose processor to perform the required tasks, or the processing unit may be dedicated to performing the required functions. In another embodiment of the present disclosure, the modules 306 may be machine-readable instructions (software) that, when executed by a processor / processing unit, perform any of the described functionalities. Furthermore, the data serves, amongst other things, as a repository for storing data processed, received, and generated by one or more of the modules. The modules 306 may include a determining module 308, an applying module 310, an encoding module 312, and a transmitting module 314. In addition, the modules 306 may further include a receiving module. Furthermore, the transmitting module 314 and the receiving module may be integrated as a transceiving module.

[0071] Additionally, the system 208 may be implemented within the receiver 204. The system 208 may include a processor 318, a memory 320, one or more modules 322 (referred to herein as the modules), and an interface 330. The processor 318 may be in communication with the memory 320, modules 322, and the interface 330. The constructional and operational features of the processor 318, a memory 320, modules 322, and the interface 330 may be the same as the processor 302, a memory 304, modules 306, and the interface 316. Thus, the same has not been explained for the sake of brevity. Herein, the modules 322 may include a transmitting module 324, a receiving module 326, and a decoding module 328. Furthermore, the transmitting module 324 and the receiving module 326 may be integrated as a transceiving module.

[0072] The operation performed by each of the modules 306, 322 to perform the channel coding and the channel decoding may be explained in the subsequent paragraphs in conjunction with Figures 4A and 4B.

[0073] Figure 4A illustrates a flowchart of steps performed by the system 206 to perform the channel coding, in accordance with an embodiment of the present disclosure. Figure 4Billustrates a block diagram for identification of the coding scheme by the transmitter 202, in accordance with an embodiment of the present disclosure. Figures 4A and 4B may be explained in conjunction for the sake of brevity.

[0074] In an embodiment, at step 402, the determining module 308 may be configured to determine one of a coding scheme or an application of a pre-processing operation on the coding scheme based on a plurality of parameters. The plurality of parameters may include, but is not limited to, a code length, information bit length, a code rate, a Modulation and Coding Scheme (MCS) index, rate matching length, resource allocation parameters such as resource blocks, number of time domain symbols, signal strength, a data type, an equipment type, a signal to noise ratio, an error rate, and a service type. The data type may include control data or user data such as data transmitted through Physical Uplink Shared Channel (PUSCH) / Physical Uplink Control Channel (PUCCH) / Physical Downlink Control Channel (PDCCH) / Physical Downlink Shared Channel (PDSCH) / Physical broadcast channel (PBCH) channels. Further, the service type may include Ultra-Reliable Low Latency Communication (URLLC), Enhanced Mobile Broadband (emBB), Internet of Things (IoT), hyper-relaible low latency communication (HRLLC), immersive communication (IC), UE, any other services of next generation. The error rate may include a bit error rate and a block error rate. The UE type may indicate different categories of the UE.

[0075] In such an embodiment, the determining module 308 may consider the plurality of parameters, for example, the signl strength, the data type, data length, available grant / resource, the code rate, etc. Then, the determining module 308 may determine, dynamically, the coding scheme or the application of the pre-processing operation on the coding scheme based on the plurality of parameters. Alternatively, the determining module 308 may consider the plurality of parameters for concatenation to the channel coding and indicate through at least one of a Radio Resource Control (RRC) configuration message, medium access control element (MAC CE) and a Downlink Control Information (DCI) message, respectively.

[0076] Herein, the coding scheme may correspond to one of a polar code (interchangeably referred to as polar codes), a Low-Density Parity-Check (LDPC) code (interchangeably referred to as LDPC codes), a turbo code, a polar-based code, such as, PAC codes, a block code, a repetition code, or a reed-muller code.

[0077] In an example, the determining module 308 may consider the following parameters as an input, as shown in Figure 4B, to dynamically determine the coding scheme or the application of the pre-processing operation on the coding scheme. The inputs may include the signal strength, data type, data length, available grant / resources, and code rate. The signal strength may include downlink, that is, using measurements received from downlink transmissions and uplink, that is, measurements made on the configured uplink transmission. The downlink may include SSB based and CSI-RS based. Further, each of the SSB-based and CSI-RS based may include RSRP / RSRQ / SINR. The Uplink may include SRS based, where the SRS based may include RSRP / RSRQ / SINR. The data type may include control data, that is, UCI / DCI and data, that is, PDSCH / PUSCH. The data length may include Transport block (TB) size / DCI / UCI length. The available grant / resources may include Bits / Time and frequency resources.

[0078] Further, based on the code rate and the code length, the predefined usage in the third generation partnership project (3GPP) specification may include the usage of a channel coding scheme (interchangeably referred to as coding scheme) for different types of transport channels (TrCH). The channel coding scheme may be indicated in the specification of 38.212 or 6G / beyond specification for multiplexing and channel coding. For example, data channels or the user-data channels are illustrated in Table-3, Table-4, and Table-5 below. Moreover, control channels or the control-data channels are illustrated in Table-6, and Table-7 below.

[0079]

[0080] Table 3

[0081]

[0082] Table 4

[0083]

[0084] Table 5

[0085]

[0086] Table 6

[0087]

[0088] Table 7

[0089] The channel coding scheme may be selected based on the code length and code rate, which may be pre-defined. Further, the code length and code rate thresholds may be obtained using a simulation technique.

[0090] Herein, the determining module 308 may be configured to determine one of the coding scheme or the application of pre-processing on the coding scheme based on an indication received from the receiver 204. The indication may be received from the receiver 204 via one of an Uplink Control Information (UCI) message, a Physical Uplink Shared Channel (PUSCH) or MAC CE of the PUSCH. Further, the indication received from the receiver 204 may be indicative of at least one of a receiver-selected coding scheme or a decision for applying the pre-processing operation on the receiver-selected coding scheme. Additionally, the determining module 308 may be configured to determine one of the coding scheme or the application of pre-processing on the coding scheme based on a predefined code rate, information bit length, rate matching length, resource allocation parameters such as resource blocks, number of time domain symbols, and a predefined code length of a codeword.

[0091] In an embodiment, at step 404, the applying module 310 may be configured to apply a pre-processing operation on the coding scheme based on the plurality of parameters. The pre-processing operations may include, but are not limited to, one or more of a rate-k pre-transform operation, a rate-k post-transform operation, a pre-coding operation, an outer code application, or an inner code application. In such an embodiment, the applying module 310 may be configured to apply one of a rate-k convolutional code, a Reed-Solomon (RS) code, or a block code or a CRC code on the coding scheme. Further, a value of k lies in a range of 0 to 1.

[0092] In an embodiment, at step 406, the encoding module 312 may be configured to encode data to be transmitted based on the pre-processed coding scheme. The transmission data may include at least one of user data and control data.

[0093] Herein, the user-data may further include downlink data and uplink data. Therefore, for encoding the downlink data that is to be transmitted in PDSCH, a plurality of options may be provided, that is, (a). Polar, Polar variant (PAC) / Pre-transformed polar code, Low Density Parity Check (LDPC), (b). Polar, LDPC, (c). Polar variant (PAC) / Pre-transformed polar code, LDPC. For encoding the uplink data that is to be transmitted in PUSCH, a plurality of options may be provided, that is, (a). Polar, Polar variant (PAC) / Pre-transformed polar code, LDPC, (b). Polar, LDPC, and (c). Polar variant (PAC) / Pre-transformed polar code, LDPC.

[0094] Additionally, the control-data may include Uplink Control Information (UCI) and Downlink Control Information (DCI). For encoding the Uplink Control Information (UCI) that is to be transmitted in PUCCH or PUSCH, a plurality of options may be provided, that is, (a). Polar, Polar variant (PAC) / pre-transformed polar code, (b). PAC / pre-transformed polar code. For encoding Downlink Control Information (DCI) that is to be transmitted either in PDCCH, a plurality of options may be provided, that is, (a). Polar, Polar variant (PAC) / pre-transformed polar code, (b). PAC / pre-transformed polar code.

[0095] In an embodiment, at step 408, the transmitting module 314 may be configured to transmit the encoded data along with one of the indication of the coding scheme or the application of the pre-processing operation on the coding scheme to the receiver 204 via a plurality of transmission channels. Herein, the transmitting module 314 may be configured to transmit one of the indication of the coding scheme or the application of pre-processing operation on the coding scheme via at least one of a Radio Resource Control (RRC) configuration message, the Downlink Control Information (DCI) message or a medium access control (MAC) control element (CE). In another embodiment, the transmitting module 314 may be configured to transmit application of the pre-transform / post-transform or outer code / inner code, without departing from the scope of the present disclosure. Herein, the transmission of the encoded data or the application of the pre-transform / post-transform or outer code / inner code indicates the channel coding.

[0096] Further, to transmit the one of the indication of the coding scheme or the application of pre-processing operation on the coding scheme, the system 206 may include a single-stage or a multi-stage indication using one or a combination of a Radio Resource Control (RRC) configuration message, a Medium Access Control (MAC) control element, and a Downlink Control Information (DCI) message. Atleast one of the message provides an initial indication of the coding scheme and atleast one other message provides a down-selection of the coding scheme.

[0097] In an exemplary embodiment, a plurality of options are provided for the channel coding / encoding of UCI-PUCCH, UCI-PUSCH, where option 1a may be explained as follows:

[0098] Herein, in the context of channel coding of UCI-PUCCH, UCI-PUSCH by the transmitter 202, A represents the length of the UCI bit sequence. When A is less than or equal to a certain threshold , the block code may be used for encoding by the encoding module 312. However, if A is greater than or equal to +1, the choice of encoding technique depends on the ratio K / E, where K is the sum of A and the CRC (Cyclic Redundancy Check) length, and E is the length of the encoded bit sequence. If this ratio K / E is less than or equal to a threshold Rth, then either PAC codes may be used, or a pre-transform may be applied to polar codes to enhance performance. If K / E exceeds Rth, the polar codes are used. The values of and Rthare not fixed but are typically determined through link-level simulation studies across various channel models, aimed at achieving the desired key performance indicators (KPIs). The channel coding may be represented as below:

[0099] A denotes the length of UCI bit sequence.

[0100] For , block code may be used.

[0101] For

[0102] If

[0103] PAC codes or enable pre-transform on polar codes

[0104] Else

[0105] Polar codes

[0106] Where, K = A + CRC length

[0107] and Rthmay be identified through link level simulation analysis with different channel models, that yields the desirable KPIs.

[0108] For UCI-PUCCH, block codes are selected for very small lengths, that is, up to approximately 2 bits; otherwise, PAC codes are selected for lower code rates, and the polar codes are selected for higher code rates.

[0109] Option 1b of the channel coding of UCI-PUCCH, UCI-PUSCH, may be explained as follows:

[0110] Herein, for channel coding of the UCI-PUCCH, UCI-PUSCH by the encoding module 312, A represents the length of the UCI bit sequence. When A is less than or equal to a threshold value , block codes may be used for encoding by the encoding module 312. If A falls within the range +1 to , polar codes are used. However, when A exceeds , either PAC codes or polar codes with an enabled pre-transform are employed to achieve improved performance. The variable K, used in the selection process, is defined as the sum of A and the CRC (Cyclic Redundancy Check) length. The thresholds and are typically determined through link-level simulations under various channel models, aiming to identify the configurations that yield the desired key performance indicators (KPIs). The channel coding may be represented as below:

[0111] A denotes the length of UCI bit sequence.

[0112] For , block code may be used.

[0113] For and

[0114] Polar Codes

[0115] Else

[0116] PAC codes or enable pre-transform on polar codes

[0117] Where, K = A + CRC length

[0118] and may be identified through link level simulation analysis with different channel models, that yields the desirable KPIs.

[0119] For UCI-PUCCH, block codes are selected for very small lengths, polar codes are selected for small lengths, and PAC codes are selected for moderate lengths.

[0120] Further, option 2 of the channel coding of UCI-PUCCH, UCI-PUSCH, may be explained as follows:

[0121] Herein, for channel coding of the UCI-PUCCH, UCI-PUSCH by the encoding module 312, A represents the length of the UCI bit sequence. When A is less than or equal to a threshold value , block codes may be used for encoding by the encoding module 312. If A is greater than or equal the range +1, PAC codes or pre-transformed / concatenated polar codes are used. The variable K, used in the selection process, is defined as the sum of A and the CRC (Cyclic Redundancy Check) length. The thresholds may be typically determined through link-level simulations under various channel models, aiming to identify the configurations that yield the desired key performance indicators (KPIs). The channel coding may be represented as below:

[0122] A denotes the length of UCI bit sequence.

[0123] For , block code may be used.

[0124] For

[0125] PAC codes or pre-transformed / concatenated polar codes

[0126] Where, K = A + CRC length

[0127] through link level simulation analysis with different channel models, that yields the desirable KPIs.

[0128] For UCI-PUCCH, the block codes are selected for A A_1, the PAC codes are chosen otherwise.

[0129] In an exemplary embodiment, a plurality of options are provided for the channel coding of UL-SCH and DL-SCH: PUSCH, PDSCH, where option 1 may be explained as follows:

[0130] In this channel coding of the UL-SCH and DL-SCH: PUSCH, PDSCH by the encoding module 312, A represents the length of the transport block. The selection of the coding technique depends on the value of A and the relationship between the information bits K (which equals the sum of A and CRC length) and the total number of encoded bits E. When the transport block size A is less than or equal to a predefined threshold , the coding scheme is chosen based on the coding rate K / E. If this coding rate is less than or equal to a threshold value Rth, then PACcodes are preferred, or alternatively, a pre-transform on the polar codes may be applied. However, if the coding rate exceeds Rth, the polar codes are used by the encoding module 312. On the other hand, for larger transport blocks where , LDPC codes are used by the encoding module 312. The optimal values for the thresholds and Rthare typically determined through link-level simulations under various channel conditions, aiming to meet specific Key Performance Indicators (KPIs). The channel coding may be represented as below:

[0131] A denotes the length of transport block.

[0132] For ,

[0133] If K / E

[0134] PAC codes or enable pre-transform on polar codes

[0135] Else

[0136] polar codes

[0137] For

[0138] LDPC codes

[0139] Where, K=A+CRC length

[0140] and may be identified through link level simulation analysis with different channel models, that yields the desirable KPIs.

[0141] The polar and PAC codes are selected for smaller lengths and LDPC codes for larger lengths. The Polar and PAC codes are selected based on the code rates, whereas the PAC codes are selected for smaller code rates.

[0142] In an exemplary embodiment, option 1a for the channel coding of the UL-SCH and the DL-SCH: PUSCH, PDSCH, may be explained as below:

[0143] In this channel coding of the UL-SCH and the DL-SCH: PUSCH, PDSCH by the encoding module 312, A represents the length of the transport block. When the transport block size A is less than or equal to a predefined threshold , the polar codes may be used for encoding by the encoding module 312. If A falls within the range to or equals to , PAC codes or pre-transform on polar codes may be used by the encoding module 312. However, when A exceeds , LDPC codes are used by the encoding module 312. The variable K, used in the selection process, is defined as the sum of A and the CRC (Cyclic Redundancy Check) length. The thresholds and are typically determined through link-level simulations under various channel models, aiming to identify the configurations that yield the desired key performance indicators (KPIs). The channel coding may be represented as below:

[0144] A denotes the length of transport block.

[0145] For ,

[0146] Polar Codes

[0147] For and

[0148] PAC codes or enable pre-transform on polar codes

[0149] For

[0150] LDPC codes

[0151] Where, K=A+CRC length

[0152] and may be identified through link level simulation analysis with different channel models, that yields the desirable KPIs.

[0153] The polar and PAC codes are selected for smaller lengths and LDPC codes for larger lengths. The Polar codes are selected for very small lengths and PAC codes are selected for lengths greater than that of the polar codes.

[0154] Furthermore, option 2 of the channel coding of the UL-SCH and the DL-SCH: PUSCH, PDSCH, may be explained as follows:

[0155] Herein, for channel coding of the UL-SCH and the DL-SCH: PUSCH, PDSCH by the encoding module 312, A represents the length of the transport block. When A is less than or equal to a threshold value , polar codes may be used for encoding by the encoding module 312. If A is greater than or equal the range +1, LDPC codes are used. The variable K, used in the selection process, is defined as the sum of A and the CRC (Cyclic Redundancy Check) length. The thresholds may be typically determined through link-level simulations under various channel models, aiming to identify the configurations that yield the desired key performance indicators (KPIs). The channel coding may be represented as below:

[0156] A denotes the length of transport block.

[0157] For ,

[0158] Polar codes

[0159] For

[0160] LDPC codes

[0161] Where, K=A+CRC length

[0162] may be identified through link level simulation analysis with different channel models, that yields the desirable KPIs.

[0163] The polar codes are selected for smaller lengths, and LDPC codes are selected for larger lengths.

[0164] Additionally, option 3 of the channel coding of the UL-SCH and the DL-SCH: PUSCH, PDSCH, may be explained as follows:

[0165] Herein, for channel coding of the UL-SCH and the DL-SCH: PUSCH, PDSCH by the encoding module 312, A represents the length of the transport block. When A is less than or equal to a threshold value , PAC codes or pre-transform on polar codes may be used by the encoding module 312. If A is greater than or equal the range +1, LDPC codes are used. The variable K, used in the selection process, is defined as the sum of A and the CRC (Cyclic Redundancy Check) length. The thresholds may be typically determined through link-level simulations under various channel models, aiming to identify the configurations that yield the desired key performance indicators (KPIs). The channel coding may be represented as below:

[0166] A denotes the length of transport block.

[0167] For ,

[0168] PAC codes or enable pre-transform on polar codes

[0169] For

[0170] LDPC codes

[0171] Where, K=A+CRC length

[0172] may be identified through link level simulation analysis with different channel models, that yields the desirable KPIs.

[0173] The PAC codes or pre-transformed codes are selected for smaller lengths, and LDPC codes are selected for larger lengths.

[0174] In an exemplary embodiment, a plurality of options are provided for the channel coding of DCI:PDCCH, where option 1 may be explained as follows:

[0175] Herein, for channel coding of the DCI:PDCCH by the encoding module 312, A represents the length of the DCI (Downlink Control Information) bit sequence. The choice of coding method depends on both the value of A and the code rate R. When A is less than or equal to a threshold value and the code rate R is greater than a threshold Rth1, or when A is less than or equal to another threshold , the polar codes are used by the encoding module 312. In all other scenarios, either PAC codes are used, or a pre-transform is applied to enhance the performance of the polar codes. The specific threshold values , ,Rth1, and Rthare determined through link-level simulation analysis across various channel models. These simulations aim to identify the optimal parameters that meet the desired Key Performance Indicators (KPIs). Further, the channel coding may be represented as below:

[0176] A denotes the length of DCI bit sequence.

[0177] For and R > Rth1or

[0178] Polar code is used

[0179] Otherwise

[0180] PAC codes or enable pre-transform on polar codes

[0181] Where, , , Rth1and Rthmay be identified through link level simulation analysis with different channel models, that yield the desirable KPIs.

[0182] Herein, for DCI-PDCCH, the polar codes are selected for smaller DCI or higher length DCI with smaller code rates. Otherwise, the PAC codes or pre-transformed polar codes are selected.

[0183] In an exemplary embodiment, option 2 of the channel coding of DCI:PDCCH, may be explained as below:

[0184] A denotes the length of DCI bit sequence.

[0185] Encode the DCI using PAC Codes.

[0186] For DCI-PUCCH, the PAC codes or pre-transformed polar codes are used.

[0187] In an embodiment, the channel decoding may be explained in subsequent paragraphs in conjunction with Figure 4C.

[0188] Figure 4C illustrates an operation performed by the system 208 to perform the channel decoding, in accordance with an embodiment of the present disclosure.

[0189] In an embodiment, referring to Figure 4C, at step 410, initially, the transmitting module 324 may be configured to transmit the indication via one of the Uplink Control Information (UCI) message or the Physical Uplink Shared Channel (PUSCH). The indication may be indicative of at least one of the receiver-selected coding scheme or the decision for applying the pre-processing operation on the receiver-selected coding scheme. Additionally, the indication may be also indicative of precoder / concatenation / outer code / inner code. The transmitting module 324 may be configured to transmit the indication to the transmitter 202.

[0190] Thereafter, at step 412, the receiving module 326 may be configured to receive the encoded data along with one of the indication of the coding scheme or the application of the pre-processing operation on the coding scheme. The coding scheme corresponds to one of the polar code, the Low-Density Parity-Check (LDPC) code, the turbo code, the polar-based code, the block code, the repetition code, or the reed-muller code. The receiving module 326 may be configured to receive the encoded data from the transmitter 202 via the plurality of transmission channels. Herein, one of the coding scheme or the application of the pre-processing operation on the coding scheme is determined by the transmitter 202 based on the plurality of parameters. the plurality of parameters may include the code length, the information bit length, the code rate, the Modulation and Coding Scheme (MCS) index, the rate matching length, the resource allocation parameters such as resource blocks, the number of time domain symbols, the signal strength, the data type, the equipment type, and the service type. Further, the receiving module 326 may be configured to receive one of the indication of the coding scheme or the application of the pre-processing operation on the coding scheme via at least one of the Radio Resource Control (RRC) configuration message, MAC CE, or the Downlink Control Information (DCI) message from the transmitter 202.

[0191] Further, to receive the one of the indication of the coding scheme or the application of the pre-processing operation on the coding scheme, the system 208 may include the single-stage or the multi-stage indication using one or the combination of thw Radio Resource Control (RRC) configuration message, a Medium Access Control (MAC) control element, and the Downlink Control Information (DCI) message. Atleast one of the message provides the initial indication of the coding scheme and atleast one other message provides the down-selection of the coding scheme

[0192] In such an embodiment, when the transmitting module 324 may be configured to decide the channel coding scheme and indicates to the transmitter 202 through the UCI message, the parameters (described in the subsequent paragraphs) may be considered.

[0193] The receiver 204 may use the channel estimates on the configured reference signals and then report the preferred channel coding scheme or the choice of applying rate-k pre-transform / precoder / concatenation / outer code / inner code to obtain a certain BLER for a given code rate. The receiver 204 may predict the right channel coding scheme along with the Channel Quality Indicator (CQI). Herein, the inputs may be SSB / CSI-RS channel estimates, and PDCCH DMRS / PDCCH RE / PDSCH DMRS / PDSCH RE channel estimates. The receiver 204 may indicate the preferred channel coding scheme or the choice of applying rate-k pre-transform / precoder / concatenation / outer code / inner code through the UCI message on PUCCH (Format 2 / 3 / 4) or on PUSCH, with UCI multiplexing. The transmitter 202 may indicate the channel coding scheme or the choice of applying rate-k pre-transform / precoder / concatenation / outer code / inner code through one of the following methods, that is, DCI message and RRC configuration message.

[0194] Further, for mMTC and Ambient-IoT technologies, the transport block in both uplink and downlink data and control channels may be encoded using the following codes, that is, Polar code and Pre-transformed polar code or PAC code, after CRC attachment.

[0195] Herein, the RRC configuration message includes PUCCH-Config, PUCCH-ConfigCommon, PUSCH-Config, PUSCH-ConfigCommon, PDCCH-Config, PDCCH-ConfigCommon, and PDSCH-Config, PDSCH-ConfigCommon, PBCH-Config.

[0196] Further, the applicability of the RRC configuration message may be UCI-PUCCH, UCI-PUSCH, Data-PUSCH, Data-PDSCH,DCI-PDCCH, MIB-PBCH.

[0197] Further, the indication of the coding scheme through the RRC configuration message may be described hereinbelow.

[0198] The configuration for the indication of coding scheme may be a part of the RRC configuration message for common and dedicated channels. The receiver 204 may indicate a capability on support of the channel coding schemes for both control and data channels or the user-data and the control data. Based on the capability, transmitter 202 may indicate the right channel coding scheme through RRC configuration message.

[0199] Further, the Data-PDSCH / PUSCH may be indicated in PDSCH-Config / PUSCH-Config or PDSCH-ConfigCommon / PUSCH-ConfigCommon. The UCI-PUCCH may be specified for certain PUCCH formats such as Format 2, Format 3, and Format 4 as Formats 0 and 1 support only upto 2 bits of UCI, for which block codes are preferable. Further, the UCI-PUCCH may be indicated in PUCCH-Config.

[0200] In the DCI-PDCCH: the indication via the RRC configuration message may be beneficial for the PDCCH in order to reduce the power consumption in PDCCH blind decodes, provided that the receiver 204 may unaware of the DCI payload size and hence the code rate, to choose the channel coding scheme. Herein, the coding scheme may be indicated based on the type of information being transmitted or the format of DCI itself (as inherently, the type of data has relation with the size and code rate of the data). For example: PDCCH for paging, UL data, DL data, RAR response, etc. There may be a table for choosing the channel coding based on the logical channel. Further, the DCI-PDCCH may be indicated in PDCCH-Config or PDCCH-ConfigCommon.

[0201] In an embodiment, for UCI-PUCCH, one of the block, polar, or PAC codes may be selected. Alternatively, polar codes or PAC codes may be selected while fixing block codes for formats 0 and 1, which carry 1 or 2 bits of HARQ ACK / NACK. Another option may be to indicate PAC codes while keeping polar codes as the default.. In an exemplary embodiment, RRC PUCCH-Config may be as follows:

[0202]

[0203] PUCCH-Config ::= SEQUENCE {

[0204] resourceSetToAddModList SEQUENCE (SIZE (1..maxNrofPUCCH-ResourceSets)) OF PUCCH-ResourceSet OPTIONAL, -- Need N

[0205] resourceSetToReleaseList SEQUENCE (SIZE (1..maxNrofPUCCH-ResourceSets)) OF PUCCH-ResourceSetId OPTIONAL, -- Need N

[0206] resourceToAddModList SEQUENCE (SIZE (1..maxNrofPUCCH-Resources)) OF PUCCH-Resource OPTIONAL, -- Need N

[0207] resourceToReleaseList SEQUENCE (SIZE (1..maxNrofPUCCH-Resources)) OF PUCCH-ResourceId OPTIONAL, -- Need N

[0208] format1 SetupRelease { PUCCH-FormatConfig } OPTIONAL, -- Need M

[0209] format2 SetupRelease { PUCCH-FormatConfig } OPTIONAL, -- Need M

[0210] format3 SetupRelease { PUCCH-FormatConfig } OPTIONAL, -- Need M

[0211] format4 SetupRelease { PUCCH-FormatConfig }

[0212] Case 1:

[0213] PUCCH-FormatConfig ::= SEQUENCE {

[0214] interslotFrequencyHopping ENUMERATED {enabled} OPTIONAL, -- Need R

[0215] additionalDMRS ENUMERATED {true} OPTIONAL, -- Need R

[0216] maxCodeRate PUCCH-MaxCodeRate OPTIONAL, -- Need R

[0217] nrofSlots ENUMERATED {n2,n4,n8} OPTIONAL, -- Need S

[0218] pi2BPSK ENUMERATED {enabled} OPTIONAL, -- Need R

[0219] simultaneousHARQ-ACK-CSI ENUMERATED {true} OPTIONAL -- Need R

[0220] codingSchemeENUMERATED {block, polar, PAC}

[0221] }

[0222]

[0223] Case 2:

[0224] PUCCH-FormatConfig ::= SEQUENCE {

[0225] interslotFrequencyHopping ENUMERATED {enabled} OPTIONAL, -- Need R

[0226] additionalDMRS ENUMERATED {true} OPTIONAL, -- Need R

[0227] maxCodeRate PUCCH-MaxCodeRate OPTIONAL, -- Need R

[0228] nrofSlots ENUMERATED {n2,n4,n8} OPTIONAL, -- Need S

[0229] pi2BPSK ENUMERATED {enabled} OPTIONAL, -- Need R

[0230] simultaneousHARQ-ACK-CSI ENUMERATED {true} OPTIONAL -- Need R

[0231] codingSchemeENUMERATED { polar, PAC}

[0232]

[0233] Case:3

[0234] PUCCH-FormatConfig ::= SEQUENCE {

[0235] interslotFrequencyHopping ENUMERATED {enabled} OPTIONAL, -- Need R

[0236] additionalDMRS ENUMERATED {true} OPTIONAL, -- Need R

[0237] maxCodeRate PUCCH-MaxCodeRate OPTIONAL, -- Need R

[0238] nrofSlots ENUMERATED {n2,n4,n8} OPTIONAL, -- Need S

[0239] pi2BPSK ENUMERATED {enabled} OPTIONAL, -- Need R

[0240] simultaneousHARQ-ACK-CSI ENUMERATED {true} OPTIONAL -- Need R

[0241] codingSchemeENUMERATED { PAC}

[0242]

[0243] Case:4

[0244] PUCCH-FormatConfig ::= SEQUENCE {

[0245] interslotFrequencyHopping ENUMERATED {enabled} OPTIONAL, -- Need R

[0246] additionalDMRS ENUMERATED {true} OPTIONAL, -- Need R

[0247] maxCodeRate PUCCH-MaxCodeRate OPTIONAL, -- Need R

[0248] nrofSlots ENUMERATED {n2,n4,n8} OPTIONAL, -- Need S

[0249] pi2BPSK ENUMERATED {enabled} OPTIONAL, -- Need R

[0250] simultaneousHARQ-ACK-CSI ENUMERATED {true} OPTIONAL -- Need R

[0251] codingTransformPrecoder ENUMERATED{enabled, disabled}

[0252]

[0253]

[0254] In an exemplary embodiment, RRC PDSCH-Config may be as follows:

[0255]

[0256] Option:1

[0257] PDSCH-Config ::= SEQUENCE {

[0258] dataScramblingIdentityPDSCH INTEGER (0..1023) OPTIONAL, -- Need S

[0259] dmrs-DownlinkForPDSCH-MappingTypeA SetupRelease { DMRS-DownlinkConfig } OPTIONAL, -- Need M

[0260] dmrs-DownlinkForPDSCH-MappingTypeB SetupRelease { DMRS-DownlinkConfig } OPTIONAL, -- Need M

[0261]

[0262] tci-StatesToAddModList SEQUENCE (SIZE(1..maxNrofTCI-States)) OF TCI-State OPTIONAL, -- Need N

[0263] tci-StatesToReleaseList SEQUENCE (SIZE(1..maxNrofTCI-States)) OF TCI-StateId OPTIONAL, -- Need N

[0264] vrb-ToPRB-Interleaver ENUMERATED {n2, n4} OPTIONAL, -- Need S

[0265] resourceAllocation ENUMERATED { resourceAllocationType0, resourceAllocationType1, dynamicSwitch},

[0266] pdsch-TimeDomainAllocationList SetupRelease { PDSCH-TimeDomainResourceAllocationList } OPTIONAL, -- OPTIONAL, -- Need S

[0267] .

[0268] .

[0269] .

[0270] .

[0271] .

[0272] mcs-Table ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need S

[0273] maxNrofCodeWordsScheduledByDCI ENUMERATED {n1, n2}

[0274] codingSchemeENUMERATED {ldpc, polar, PAC} or ENUMERATED{polar, PAC} / ldpc may be default

[0275]

[0276] Option:2

[0277] PDSCH-Config ::= SEQUENCE {

[0278] dataScramblingIdentityPDSCH INTEGER (0..1023) OPTIONAL, -- Need S

[0279] dmrs-DownlinkForPDSCH-MappingTypeA SetupRelease { DMRS-DownlinkConfig } OPTIONAL, -- Need M

[0280] dmrs-DownlinkForPDSCH-MappingTypeB SetupRelease { DMRS-DownlinkConfig } OPTIONAL, -- Need M

[0281]

[0282] tci-StatesToAddModList SEQUENCE (SIZE(1..maxNrofTCI-States)) OF TCI-State OPTIONAL, -- Need N

[0283] tci-StatesToReleaseList SEQUENCE (SIZE(1..maxNrofTCI-States)) OF TCI-StateId OPTIONAL, -- Need N

[0284] vrb-ToPRB-Interleaver ENUMERATED {n2, n4} OPTIONAL, -- Need S

[0285] resourceAllocation ENUMERATED { resourceAllocationType0, resourceAllocationType1, dynamicSwitch},

[0286] pdsch-TimeDomainAllocationList SetupRelease { PDSCH-TimeDomainResourceAllocationList } OPTIONAL, -- OPTIONAL, -- Need S

[0287] .

[0288] .

[0289] .

[0290] .

[0291] .

[0292] mcs-Table ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need S

[0293] maxNrofCodeWordsScheduledByDCI ENUMERATED {n1, n2}

[0294] codingSchemeENUMERATED {ldpc, polar} or ENUMERATED{polar} / ldpc may be default

[0295]

[0296] Option 3:

[0297] PDSCH-Config ::= SEQUENCE {

[0298] dataScramblingIdentityPDSCH INTEGER (0..1023) OPTIONAL, -- Need S

[0299] dmrs-DownlinkForPDSCH-MappingTypeA SetupRelease { DMRS-DownlinkConfig } OPTIONAL, -- Need M

[0300] dmrs-DownlinkForPDSCH-MappingTypeB SetupRelease { DMRS-DownlinkConfig } OPTIONAL, -- Need M

[0301]

[0302] tci-StatesToAddModList SEQUENCE (SIZE(1..maxNrofTCI-States)) OF TCI-State OPTIONAL, -- Need N

[0303] tci-StatesToReleaseList SEQUENCE (SIZE(1..maxNrofTCI-States)) OF TCI-StateId OPTIONAL, -- Need N

[0304] vrb-ToPRB-Interleaver ENUMERATED {n2, n4} OPTIONAL, -- Need S

[0305] resourceAllocation ENUMERATED { resourceAllocationType0, resourceAllocationType1, dynamicSwitch},

[0306] pdsch-TimeDomainAllocationList SetupRelease { PDSCH-TimeDomainResourceAllocationList } OPTIONAL, -- OPTIONAL, -- Need S

[0307] .

[0308] .

[0309] .

[0310] .

[0311] .

[0312] mcs-Table ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need S

[0313] maxNrofCodeWordsScheduledByDCI ENUMERATED {n1, n2}

[0314] codingSchemeENUMERATED {ldpc, PAC} or ENUMERATED{PAC} / ldpc may be default

[0315]

[0316] For PDSCH, one of LDPC, polar, or PAC codes may be configured via the RRC configuration message. Alternatively, a choice between polar and PAC codes may be configured, assuming LDPC codes are used by default if not explicitly configured. Another option is to configure either LDPC and polar codes or LDPC and PAC codes.

[0317]

[0318] Option 4:

[0319] PDSCH-Config ::= SEQUENCE {

[0320] dataScramblingIdentityPDSCH INTEGER (0..1023) OPTIONAL, -- Need S

[0321] dmrs-DownlinkForPDSCH-MappingTypeA SetupRelease { DMRS-DownlinkConfig } OPTIONAL, -- Need M

[0322] dmrs-DownlinkForPDSCH-MappingTypeB SetupRelease { DMRS-DownlinkConfig } OPTIONAL, -- Need M

[0323]

[0324] tci-StatesToAddModList SEQUENCE (SIZE(1..maxNrofTCI-States)) OF TCI-State OPTIONAL, -- Need N

[0325] tci-StatesToReleaseList SEQUENCE (SIZE(1..maxNrofTCI-States)) OF TCI-StateId OPTIONAL, -- Need N

[0326] vrb-ToPRB-Interleaver ENUMERATED {n2, n4} OPTIONAL, -- Need S

[0327] resourceAllocation ENUMERATED { resourceAllocationType0, resourceAllocationType1, dynamicSwitch},

[0328] pdsch-TimeDomainAllocationList SetupRelease { PDSCH-TimeDomainResourceAllocationList } OPTIONAL, -- OPTIONAL, -- Need S

[0329] .

[0330] .

[0331] .

[0332] .

[0333] .

[0334] mcs-Table ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need S

[0335] maxNrofCodeWordsScheduledByDCI ENUMERATED {n1, n2}

[0336] codingTransformPrecoder ENUMERATED{enabled, disabled}

[0337]

[0338] In an exemplary embodiment, RRC PDSCH-ConfigCommon may be as follows:

[0339]

[0340] Option 1:

[0341] PDSCH-ConfigCommon ::= SEQUENCE {

[0342] pdsch-TimeDomainAllocationList PDSCH-TimeDomainResourceAllocationList OPTIONAL, -- Need R

[0343] ...

[0344] codingSchemeENUMERATED {ldpc, polar, PAC} or ENUMERATED{polar, PAC} / ldpc may be default

[0345] }

[0346]

[0347] Option 2:

[0348] PDSCH-ConfigCommon ::= SEQUENCE {

[0349] pdsch-TimeDomainAllocationList PDSCH-TimeDomainResourceAllocationList OPTIONAL, -- Need R

[0350] ...

[0351] codingSchemeENUMERATED {ldpc, polar} or ENUMERATED{polar} / ldpc may be default

[0352] }

[0353]

[0354] Option 3:

[0355]

[0356] PDSCH-ConfigCommon ::= SEQUENCE {

[0357] pdsch-TimeDomainAllocationList PDSCH-TimeDomainResourceAllocationList OPTIONAL, -- Need R

[0358] ...

[0359] codingSchemeENUMERATED {ldpc, PAC} or ENUMERATED{PAC} / ldpc may be default

[0360] }

[0361]

[0362] Option 4:

[0363]

[0364] PDSCH-ConfigCommon ::= SEQUENCE {

[0365] pdsch-TimeDomainAllocationList PDSCH-TimeDomainResourceAllocationList OPTIONAL, -- Need R

[0366] ...

[0367] codingTransformPrecoder ENUMERATED{enabled, disabled}

[0368] }

[0369]

[0370] For PDSCH Common, the coding scheme may be configured by the RRC configuration message in one of the following manner, that is, one of the LDPC, polar, or PAC codes may be configured, alternatively, either polar or PAC codes may be configured, in which case the LDPC codes may be used by default, if no configuration is provided, or LDPC codes and Polar codes or LDPC codes and PAC codes may be configured.

[0371]

[0372] In an exemplary embodiment, RRC PUSCH-Config may be as follows:

[0373]

[0374] Option 1:

[0375] PUSCH-Config ::= SEQUENCE {

[0376] dataScramblingIdentityPUSCH INTEGER (0..1023) OPTIONAL, -- Need S

[0377] txConfig ENUMERATED {codebook, nonCodebook} OPTIONAL, -- Need S

[0378] dmrs-UplinkForPUSCH-MappingTypeA SetupRelease { DMRS-UplinkConfig } OPTIONAL, -- Need M

[0379] dmrs-UplinkForPUSCH-MappingTypeB SetupRelease { DMRS-UplinkConfig } OPTIONAL, -- Need M

[0380] pusch-PowerControl .

[0381] .

[0382] OPTIONAL, -- Need M

[0383] resourceAllocation ENUMERATED { resourceAllocationType0, resourceAllocationType1, dynamicSwitch},

[0384] pusch-TimeDomainAllocationList SetupRelease { PUSCH-TimeDomainResourceAllocationList } OPTIONAL, -- Need M

[0385] pusch-AggregationFactor ENUMERATED { n2, n4, n8 } OPTIONAL, -- Need S

[0386] mcs-Table ENUMERATED {qam256, qam64LowSE} .

[0387] .

[0388] OPTIONAL, -- Need S

[0389] uci-OnPUSCH SetupRelease { UCI-OnPUSCH} OPTIONAL, -- Need M

[0390] tp-pi2BPSK ENUMERATED {enabled}

[0391] codingSchemeENUMERATED {ldpc, polar, PAC} or ENUMERATED{polar, PAC} / ldpc may be default

[0392]

[0393] Option 2:

[0394] PUSCH-Config ::= SEQUENCE {

[0395] dataScramblingIdentityPUSCH INTEGER (0..1023) OPTIONAL, -- Need S

[0396] txConfig ENUMERATED {codebook, nonCodebook} OPTIONAL, -- Need S

[0397] dmrs-UplinkForPUSCH-MappingTypeA SetupRelease { DMRS-UplinkConfig } OPTIONAL, -- Need M

[0398] dmrs-UplinkForPUSCH-MappingTypeB SetupRelease { DMRS-UplinkConfig } OPTIONAL, -- Need M

[0399] pusch-PowerControl .

[0400] .

[0401] OPTIONAL, -- Need M

[0402] resourceAllocation ENUMERATED { resourceAllocationType0, resourceAllocationType1, dynamicSwitch},

[0403] pusch-TimeDomainAllocationList SetupRelease { PUSCH-TimeDomainResourceAllocationList } OPTIONAL, -- Need M

[0404] pusch-AggregationFactor ENUMERATED { n2, n4, n8 } OPTIONAL, -- Need S

[0405] mcs-Table ENUMERATED {qam256, qam64LowSE} .

[0406] .

[0407] OPTIONAL, -- Need S

[0408] uci-OnPUSCH SetupRelease { UCI-OnPUSCH} OPTIONAL, -- Need M

[0409] tp-pi2BPSK ENUMERATED {enabled}

[0410] codingSchemeENUMERATED {ldpc, polar} or ENUMERATED{polar} / ldpc may be default

[0411]

[0412] Option 3:

[0413] PUSCH-Config ::= SEQUENCE {

[0414] dataScramblingIdentityPUSCH INTEGER (0..1023) OPTIONAL, -- Need S

[0415] txConfig ENUMERATED {codebook, nonCodebook} OPTIONAL, -- Need S

[0416] dmrs-UplinkForPUSCH-MappingTypeA SetupRelease { DMRS-UplinkConfig } OPTIONAL, -- Need M

[0417] dmrs-UplinkForPUSCH-MappingTypeB SetupRelease { DMRS-UplinkConfig } OPTIONAL, -- Need M

[0418] pusch-PowerControl .

[0419] .

[0420] OPTIONAL, -- Need M

[0421] resourceAllocation ENUMERATED { resourceAllocationType0, resourceAllocationType1, dynamicSwitch},

[0422] pusch-TimeDomainAllocationList SetupRelease { PUSCH-TimeDomainResourceAllocationList } OPTIONAL, -- Need M

[0423] pusch-AggregationFactor ENUMERATED { n2, n4, n8 } OPTIONAL, -- Need S

[0424] mcs-Table ENUMERATED {qam256, qam64LowSE} .

[0425] .

[0426] OPTIONAL, -- Need S

[0427] uci-OnPUSCH SetupRelease { UCI-OnPUSCH} OPTIONAL, -- Need M

[0428] tp-pi2BPSK ENUMERATED {enabled}

[0429] codingSchemeENUMERATED {ldpc, PAC} or ENUMERATED{PAC} / ldpc may be default

[0430]

[0431] For PUSCH, one of the LDPC codes, polar codes, or the PAC codes may be configured by the RRC configuration message. Alternatively, only the polar codes or the PAC codes may be configured, in which case LDPC codes may be assumed by default if no configuration is provided. Further, it is possible to configure either LDPC codes with the polar codes or the LDPC codes with the PAC codes.

[0432]

[0433] Option 4:

[0434]

[0435] PUSCH-Config ::= SEQUENCE {

[0436] dataScramblingIdentityPUSCH INTEGER (0..1023) OPTIONAL, -- Need S

[0437] txConfig ENUMERATED {codebook, nonCodebook} OPTIONAL, -- Need S

[0438] dmrs-UplinkForPUSCH-MappingTypeA SetupRelease { DMRS-UplinkConfig } OPTIONAL, -- Need M

[0439] dmrs-UplinkForPUSCH-MappingTypeB SetupRelease { DMRS-UplinkConfig } OPTIONAL, -- Need M

[0440] pusch-PowerControl .

[0441] .

[0442] OPTIONAL, -- Need M

[0443] resourceAllocation ENUMERATED { resourceAllocationType0, resourceAllocationType1, dynamicSwitch},

[0444] pusch-TimeDomainAllocationList SetupRelease { PUSCH-TimeDomainResourceAllocationList } OPTIONAL, -- Need M

[0445] pusch-AggregationFactor ENUMERATED { n2, n4, n8 } OPTIONAL, -- Need S

[0446] mcs-Table ENUMERATED {qam256, qam64LowSE} .

[0447] .

[0448] OPTIONAL, -- Need S

[0449] uci-OnPUSCH SetupRelease { UCI-OnPUSCH} OPTIONAL, -- Need M

[0450] tp-pi2BPSK ENUMERATED {enabled}

[0451] codingTransformPrecoder ENUMERATED{enabled, disabled}

[0452]

[0453] In an exemplary embodiment, RRC PUSCH-ConfigCommon may be as follows:

[0454]

[0455] Option 1:

[0456] PUSCH-ConfigCommon ::= SEQUENCE {

[0457] groupHoppingEnabledTransformPrecoding ENUMERATED {enabled} OPTIONAL, -- Need R

[0458] pusch-TimeDomainAllocationList PUSCH-TimeDomainResourceAllocationList OPTIONAL, -- Need R

[0459] msg3-DeltaPreamble INTEGER (-1..6) OPTIONAL, -- Need R

[0460] p0-NominalWithGrant INTEGER (-202..24) OPTIONAL, -- Need R

[0461] ...

[0462] codingSchemeENUMERATED {ldpc, polar, PAC} or ENUMERATED{polar, PAC} / ldpc may be default

[0463] }

[0464]

[0465] Option 2:

[0466] PUSCH-ConfigCommon ::= SEQUENCE {

[0467] groupHoppingEnabledTransformPrecoding ENUMERATED {enabled} OPTIONAL, -- Need R

[0468] pusch-TimeDomainAllocationList PUSCH-TimeDomainResourceAllocationList OPTIONAL, -- Need R

[0469] msg3-DeltaPreamble INTEGER (-1..6) OPTIONAL, -- Need R

[0470] p0-NominalWithGrant INTEGER (-202..24) OPTIONAL, -- Need R

[0471] ...

[0472] codingSchemeENUMERATED {ldpc, polar} or ENUMERATED{polar} / ldpc may be default

[0473] }

[0474]

[0475] Option 3:

[0476] PUSCH-ConfigCommon ::= SEQUENCE {

[0477] groupHoppingEnabledTransformPrecoding ENUMERATED {enabled} OPTIONAL, -- Need R

[0478] pusch-TimeDomainAllocationList PUSCH-TimeDomainResourceAllocationList OPTIONAL, -- Need R

[0479] msg3-DeltaPreamble INTEGER (-1..6) OPTIONAL, -- Need R

[0480] p0-NominalWithGrant INTEGER (-202..24) OPTIONAL, -- Need R

[0481] ...

[0482] codingSchemeENUMERATED {ldpc, PAC} or ENUMERATED{ PAC} / ldpc may be default

[0483]

[0484] Option 4:

[0485] PUSCH-ConfigCommon ::= SEQUENCE {

[0486] groupHoppingEnabledTransformPrecoding ENUMERATED {enabled} OPTIONAL, -- Need R

[0487] pusch-TimeDomainAllocationList PUSCH-TimeDomainResourceAllocationList OPTIONAL, -- Need R

[0488] msg3-DeltaPreamble INTEGER (-1..6) OPTIONAL, -- Need R

[0489] p0-NominalWithGrant INTEGER (-202..24) OPTIONAL, -- Need R

[0490] ...

[0491] codingTransformPrecoder ENUMERATED{enabled, disabled}

[0492]

[0493] For PUSCH common, one of the LPDC codes, the polar codes, or the PAC codes may be configured by the RRC configuration message. Alternatively, the RRC configuration message may configure only the polar codes or the PAC codes, with LDPC codes assumed as the default if no configuration is provided. It is also possible to configure a combination of LDPC and Polar or LDPC and PAC.

[0494]

[0495] In an exemplary embodiment, RRC PDCCH-Config, PDCCH-ConfigCommon may be as follows:

[0496]

[0497] PDCCH-Config ::= SEQUENCE {

[0498] controlResourceSetToAddModList SEQUENCE(SIZE (1..3)) OF ControlResourceSet OPTIONAL, -- Need N

[0499] controlResourceSetToReleaseList SEQUENCE(SIZE (1..3)) OF ControlResourceSetId OPTIONAL, -- Need N

[0500] searchSpacesToAddModList SEQUENCE(SIZE (1..10)) OF SearchSpaceOPTIONAL, -- Need N

[0501] searchSpacesToReleaseList SEQUENCE(SIZE (1..10)) OF SearchSpaceId OPTIONAL, -- Need N

[0502] downlinkPreemption SetupRelease { DownlinkPreemption } OPTIONAL, -- Need M

[0503] tpc-PUSCH SetupRelease { PUSCH-TPC-CommandConfig } OPTIONAL, -- Need M

[0504] tpc-PUCCH SetupRelease { PUCCH-TPC-CommandConfig } OPTIONAL, -- Need M

[0505] tpc-SRS SetupRelease { SRS-TPC-CommandConfig} OPTIONAL, -- Need M

[0506] ...

[0507] }

[0508] PDCCH-ConfigCommon ::= SEQUENCE {

[0509] controlResourceSetZero OPTIONAL, -- Cond InitialBWP-Only

[0510] commonControlResourceSet ControlResourceSet OPTIONAL, -- Need R

[0511] searchSpaceZero OPTIONAL, -- Cond InitialBWP-Only

[0512] commonSearchSpaceList SEQUENCE (SIZE(1..4)) OF SearchSpaceOPTIONAL, -- Need R

[0513] searchSpaceSIB1 SearchSpaceId OPTIONAL, -- Need S

[0514] searchSpaceOtherSystemInformation SearchSpaceId OPTIONAL, -- Need S

[0515] pagingSearchSpace SearchSpaceId OPTIONAL, -- Need S

[0516] ra-SearchSpace SearchSpaceId OPTIONAL, -- Need S

[0517] ...,

[0518] SearchSpace ::= SEQUENCE {

[0519] searchSpaceId SearchSpaceId,

[0520] controlResourceSetId ControlResourceSetId OPTIONAL, -- Cond SetupOnly

[0521] monitoringSlotPeriodicityAndOffset CHOICE {

[0522] sl1 NULL,

[0523] sl2 INTEGER (0..1),

[0524] sl4 INTEGER (0..3),

[0525] sl5 INTEGER (0..4),

[0526] sl8 INTEGER (0..7),

[0527] sl10 INTEGER (0..9),

[0528] sl16 INTEGER (0..15),

[0529] sl20 INTEGER (0..19),

[0530] sl40 INTEGER (0..39),

[0531] sl80 INTEGER (0..79),

[0532] sl160 INTEGER (0..159),

[0533] sl320 INTEGER (0..319),

[0534] sl640 INTEGER (0..639),

[0535] sl1280 INTEGER (0..1279),

[0536] sl2560 INTEGER (0..2559)

[0537] } OPTIONAL, -- Cond Setup

[0538] duration INTEGER (2..2559) OPTIONAL, -- Need S

[0539] monitoringSymbolsWithinSlot BIT STRING (SIZE (14)) OPTIONAL, -- Cond Setup

[0540] nrofCandidates SEQUENCE {

[0541] aggregationLevel1 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8},

[0542] aggregationLevel2 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8},

[0543] aggregationLevel4 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8},

[0544] aggregationLevel8 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8},

[0545] aggregationLevel16 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8}

[0546] }

[0547] codingSchemeENUMERATED {polar, PAC} or ENUMERATED{ PAC} / polar may be default

[0548] (or)

[0549] codingTransformPrecoder ENUMERATED{enabled, disabled} / where polar is default

[0550]

[0551] searchSpaceType CHOICE {

[0552] common SEQUENCE {

[0553] dci-Format0-0-AndFormat1-0 SEQUENCE {

[0554] ...

[0555] codingSchemeENUMERATED {polar, PAC} or ENUMERATED{ PAC} / polar may be default

[0556] (or)

[0557] codingTransformPrecoder ENUMERATED{enabled, disabled} / where polar is default

[0558] } OPTIONAL, -- Need R

[0559] dci-Format2-0 SEQUENCE {

[0560] nrofCandidates-SFI SEQUENCE {

[0561] aggregationLevel1 ENUMERATED {n1, n2} OPTIONAL, -- Need R

[0562] aggregationLevel2 ENUMERATED {n1, n2} OPTIONAL, -- Need R

[0563] aggregationLevel4 ENUMERATED {n1, n2} OPTIONAL, -- Need R

[0564] aggregationLevel8 ENUMERATED {n1, n2} OPTIONAL, -- Need R

[0565] aggregationLevel16 ENUMERATED {n1, n2} OPTIONAL -- Need R

[0566] },

[0567] ...

[0568] codingSchemeENUMERATED {polar, PAC} or ENUMERATED{ PAC} / polar may be default

[0569] (or)

[0570] codingTransformPrecoder ENUMERATED{enabled, disabled} / where polar is default

[0571] } OPTIONAL, -- Need R

[0572] dci-Format2-1 SEQUENCE {

[0573] ...

[0574] codingSchemeENUMERATED {polar, PAC} or ENUMERATED{ PAC} / polar may be default

[0575] (or)

[0576] codingTransformPrecoder ENUMERATED{enabled, disabled} / where polar is default

[0577] } OPTIONAL, -- Need R

[0578] dci-Format2-2 SEQUENCE {

[0579] ...

[0580] codingSchemeENUMERATED {polar, PAC} or ENUMERATED{ PAC} / polar may be default (or) codingTransformPrecoder ENUMERATED{enabled, disabled} / where polar is default

[0581] } OPTIONAL, -- Need R

[0582] dci-Format2-3 SEQUENCE {

[0583] dummy1 ENUMERATED {sl1, sl2, sl4, sl5, sl8, sl10, sl16, sl20} OPTIONAL, -- Cond Setup

[0584] dummy2 ENUMERATED {n1, n2},

[0585] ...

[0586] codingSchemeENUMERATED {polar, PAC} or ENUMERATED{ PAC} / polar may be default codingTransformPrecoder ENUMERATED{enabled, disabled} / where polar is default

[0587] } OPTIONAL -- Need R

[0588] },

[0589] ue-Specific SEQUENCE {

[0590] dci-Formats ENUMERATED {formats0-0-And-1-0, formats0-1-And-1-1},

[0591] ...

[0592] codingSchemeENUMERATED {polar, PAC} or ENUMERATED{ PAC} / polar may be default codingTransformPrecoder ENUMERATED{enabled, disabled} / where polar is default

[0593] }

[0594] }

[0595]

[0596] Further, the channel coding scheme for DCI-PDDCH may be indicated as a part of SearchSpace or as a part of DCI format specifier in search space type, within PDCCH-Config and PDCCH-ConfigCommon.

[0597] Herein, the DCI message may be compatible with the user-data which may select among the 3 possibilities, that is, polar codes, PAC codes, and LPDC codes. The applicability of the DCI message may be UCI-PUCCH, UCI-PUSCH, Data-PUSCH, and Data-PDSCH.

[0598] Additionally, the coding scheme may be indicated dynamically via the DCI message for UL-SCH and the DL-SCH channels. The indication for the UL-SCH and DL-SCH via the DCI message is easier, given that both the transmitter 202 and the receiver 204 possess knowledge of the length of the information bit stream. Furthermore, the transmitter 202 may signal the code rate associated with an upcoming data transmission or reception by means of DCI message. Such signaling may be implemented by utilizing reserved bits within existing DCI formats, or alternatively, through the introduction of new DCI formats in which the coding scheme is explicitly indicated, particularly in scenarios involving advanced data transmission. More details are depicted in Table-8 below:

[0599]

[0600] Table 8

[0601] In table 8, No.of Bits for Frequency domain resource assignment is determined based on .

[0602] In another embodiment, the transmitting module 314 may be configured to transmit one of the indication of the coding scheme or the application of pre-processing operation on the coding scheme via a predefined and known message, which may be known to both the transmitter 202 and the receiver 204. Herein, the predefined and known message may be part of the multiplexing and channel coding specification: 3x.212 series as part of the channel coding, where the polar and PAC codes may be selected based on the code rate or the codeword length. The applicability of the predefined and known message may be applicable to UCI-PUCCH, UCI-PUSCH, Data-PUSCH, Data-PDSCH, and DCI-PDCCH.

[0603] At step 414, the decoding module 328 may be configured to decode the received encoded data. The decoding module 328 may be configured to decode the received encoded data by applying a post-processing operation to the coding scheme. The post-processing operation may include a reverse operation of one or more of a rate-k pre-transform operation, a rate-k post-transform operation, a pre-coding operation, an outer code application, or an inner code application. Further, a value of k lies in a range of 0 to 1.

[0604] The method 500 includes a series of operations shown at step 502 through step 506 of Figure 5. The method 500 may be performed by the system 206 in conjunction with modules 306, the details of which are explained in conjunction with Figures 3 and 4A, and the same are not repeated here for the sake of brevity in the present disclosure. The method 500 begins at step 502.

[0605] At step 502, the method 500 includes applying the pre-processing operation on the coding scheme based on the plurality of parameters. The pre-processing operation may include one or more of the rate-k pre-transform operation, the rate-k post-transform operation, the pre-coding operation, the outer code application, or the inner code application. Herein, the coding scheme corresponds to one of polar code, the Low-Density Parity-Check (LDPC) code, the turbo code, the polar-based code, the block code, the repetition code, or the reed-muller code. Further, the plurality of parameters may include, but are not limited to, the code length, the information bit length, the code rate, the Modulation and Coding Scheme (MCS) index, rate matching length, resource allocation parameters such as resource blocks, number of time domain symbols, signal strength, the data type, the equipment type, and the service type.

[0606] The method 500 includes applying one of the rate-k convolutional code, the Reed-Solomon (RS) code, or the block code on the coding scheme. Further, the value of the k lies in the range of 0 to 1.

[0607] The method 500 includes determining one of the coding scheme or the application of the pre-processing operation on the coding scheme based on the plurality of parameters.

[0608] Herein, the method 500 includes determining one of the coding scheme or the pre-processing on the coding scheme based on the indication received from the receiver 204 via one of the Uplink Control Information (UCI) message, the Physical Uplink Shared Channel (PUSCH) or MAC CE of the PUSCH. The indication received from receiver 204 may be indicative of at least one of the receiver-selected coding scheme or the decision for applying the pre-processing operation on the receiver-selected coding scheme.

[0609] The method 500 includes determining one of the coding scheme or the pre-processing on the coding scheme based on the predefined code rate, information bit length, rate matching length, resource allocation parameters such as resource blocks, number of time domain symbols, and the predefined code length of the codeword.

[0610] At step 504, the method 500 includes encoding data to be transmitted based on the pre-processed coding scheme. The transmission data may include at least one of the user data or the control data.

[0611] At step 506, the method 500 includes transmitting, to the receiver 204 via the plurality of transmission channels, the encoded data along with one of the indication of the coding scheme or the application of the pre-processing operation on the coding scheme. Herein, the transmitter 202 may be one of the base station and the UE. Further, the receiver 204 may be one of the UE and the base station.

[0612] The method 500 includes transmitting one of the indication of the coding scheme or the application of the pre-processing on the coding scheme via at least one of the Radio Resource Control (RRC) configuration message, the Downlink Control Information (DCI) message or the medium access control (MAC) control element (CE). For transmitting one of the indication of the coding scheme or the application of pre-processing operation on the coding scheme, the method 500 may include the single-stage or the multi-stage indication using one or the combination of the Radio Resource Control (RRC) configuration message, the Medium Access Control (MAC) control element, and the Downlink Control Information (DCI) message. Atleast one of the message provides the initial indication of the coding scheme and atleast one other message provides the down-selection of the coding scheme.

[0613] The method 600 includes a series of operations shown at step 602 through step 604 of Figure 6. The method 600 may be performed by the system 208 in conjunction with modules 322, the details of which are explained in conjunction with Figures 3 and 4B, and the same are not repeated here for the sake of brevity in the present disclosure. The method 600 begins at step 604.

[0614] At step 602, the method 600 includes receiving, from the transmitter 202 via the plurality of transmission channels, the encoded data along with one of the indication of the coding scheme or application of the pre-processing operation on the coding scheme. The one of the coding scheme or the application of the pre-processing operation on the coding scheme is determined by the transmitter 202 based on the plurality of parameters. The plurality of parameters may include the code length, the information bit length, the code rate, the Modulation and Coding Scheme (MCS) index, rate matching length, resource allocation parameters such as resource blocks, number of time domain symbols, signal strength, the data type, the equipment type, and the service type. Further, the coding scheme may correspond to one of the polar code, the Low-Density Parity-Check (LDPC) code, the turbo code, the polar-based code, the block code, the repetition code, or the reed-muller code.

[0615] The method 600 includes receiving one of the indication of the coding scheme or the application of the pre-processing operation on the coding scheme from the transmitter 202 via at least one of the RRC configuration message, MAC CE, or the DCI message. For receiving one of the indication of the coding scheme or the application of the pre-processing operation on the coding scheme, the method 600 may include the single-stage or the multi-stage indication using one or the combination of a Radio Resource Control (RRC) configuration message, the Medium Access Control (MAC) control element, and the Downlink Control Information (DCI) message. Atleast one of the message provides an initial indication of the coding scheme and atleast one other message provides a down-selection of the coding scheme.

[0616] Prior to receiving the encoded data along with one of the indication of the coding scheme or application of the pre-processing operation on the coding scheme, the method 600 includes transmitting, to the transmitter 202, the indication via one of the Uplink Control Information (UCI) message or the Physical Uplink Shared Channel (PUSCH). The indication may be indicative of at least one of the receiver-selected coding scheme or the decision for applying the pre-processing operation on the receiver-selected coding scheme.

[0617] At step 604, the method 600 includes decoding the received encoded data based on applying the post-processing operation to the coding scheme. The post-processing operation may include the reverse operation of one or more of the rate-k pre-transform operation, the rate-k post-transform operation, the pre-coding operation, the outer code application, or the inner code application. The value of k lies in the range of 0 to 1. Herein, the transmitter 202 is one of the base station and the User Equipment (UE), and the receiver 204 is one of the UE and the base station.

[0618] As would be gathered, the systems 206 and 208 and methods 500, 600 as disclosed ensure efficient performance during the channel coding and the channel decoding, respectively, while reducing the complexity associated with the channel decoding and the channel coding. The systems 206, 208, and the methods 500, 600, as disclosed, overcome the problem of extending the 5G NR channel coding schemes to the next generation communication systems such as 6G, while maintaining compatibility with 5G. The systems 206, 208, and the methods 500, 600 ensure switching between multiple coding schemes and apply a pre-transform or precoder or concatenation to an existing channel coding scheme, to improve the performance of the system, based on the plurality of parameters such as codelength, coderate, signal strength, etc. The systems 206, 208, and the methods 500, 600 ensure signalling required from the transmitter 202 to the receiver 204 and vice versa, to make the concatenated coding feasible in 6G.

[0619] The system 206, 208, and the methods 500, 600 as disclosed, ensure improved error rate performance in order to meet the required KPIs of 6G. The system 206, 208, and the method 500, 600 ensure enabling and disabling the concatenation based on different parameters, to improve the system performance with a trade-off in complexity, while maintaining compatibility with the existing 5G system.

[0620] The systems 206 and 208, as disclosed, come under standard essential IP, for the channel coding of next generation communication systems, that is, as part of 3GPP standards.

[0621] In this application, unless specifically stated otherwise, the use of the singular includes the plural and the use of "or" means "and / or." Furthermore, use of the terms "including" or "having" is not limiting. Any range described herein will be understood to include the endpoints and all values between the endpoints. Features of the disclosed embodiments may be combined, rearranged, omitted, etc., within the scope of the disclosure to produce additional embodiments. Furthermore, certain features may sometimes be used to advantage without a corresponding use of other features.

[0622] While at least one exemplary embodiment has been presented in the foregoing detailed description, it should be appreciated that a vast number of variations exist.

Claims

1.A method (500) for channel coding performed at a transmitter (202), comprising:applying (502) a pre-processing operation on a coding scheme based on a plurality of parameters, wherein the pre-processing operation includes one or more of a rate-k pre-transform operation, a rate-k post-transform operation, a pre-coding operation, an outer code application, or an inner code application;encoding (504) data to be transmitted based on the pre-processed coding scheme, wherein the transmission data includes at least one of user data or control data; andtransmitting (506), to a receiver (204) via a plurality of transmission channels, the encoded data along with one of an indication of the coding scheme or the application of the pre-processing operation on the coding scheme.2.The method (500) of claim 1, further comprising:determining one of the coding scheme or the application of the pre-processing operation on the coding scheme based on the plurality of parameters.3.The method (500) of claim 1, wherein the plurality of parameters include a code length, a information bit length, a code rate, a Modulation and Coding Scheme (MCS) index, a rate matching length, resource allocation parameters such as resource blocks, number of time domain symbols, signal strength, a data type, an equipment type, and a service type.4.The method (500) of claim 1, wherein the coding scheme corresponds to one of a polar code, a Low-Density Parity-Check (LDPC) code, a turbo code, a polar-based code, a block code, a repetition code, or a reed-muller code.5.The method (500) of claim 1, wherein applying the pre-processing operation on the coding scheme comprises:applying one of a rate-k convolutional code, a Reed-Solomon (RS) code, or a block code on the coding scheme.6.The method (500) of claim 1, wherein a value of k lies in a range of 0 to 1.7.The method (500) of claim 1, wherein transmitting the encoded data along with one of the indication of the coding scheme or the application of pre-processing operation on the coding scheme comprises:transmitting one of the indication of the coding scheme or the application of the pre-processing on the coding scheme via at least one of a Radio Resource Control (RRC) configuration message, a Downlink Control Information (DCI) message or a medium access control (MAC) control element (CE) message.8.The method of claim 7,wherein at least one of the RRC configuration message, the MAC CE message and the DCI message provides an initial indication of the coding scheme and at least one other message provides a down-selection of the coding scheme.9.The method (500) of claim 2, wherein determining one of the coding scheme or the application of pre-processing on the coding scheme comprises:determining one of the coding scheme or the pre-processing on the coding scheme based on an indication received from the receiver (204) via one of an Uplink Control Information (UCI) message, a Physical Uplink Shared Channel (PUSCH) or MAC CE of the PUSCH, wherein the indication received from the receiver (204) is indicative of at least one of a receiver-selected coding scheme or a decision for applying the pre-processing operation on the receiver-selected coding scheme.10.The method (500) of claim 2, wherein determining one of the coding scheme or the application of the pre-processing on the coding scheme comprises:determining one of the coding scheme or the application of the pre-processing on the coding scheme based on a predefined code rate, information bit length, rate matching length, resource allocation parameters such as resource blocks, number of time domain symbols, and a predefined code length of a codeword.11.A method (600) for channel decoding performed at a receiver (204), comprising:receiving (602), from a transmitter (202) via a plurality of transmission channels, an encoded data along with one of an indication of a coding scheme or application of a pre-processing operation on the coding scheme; anddecoding (604) the received encoded data based on applying a post-processing operation to the coding scheme, wherein the post-processing operation includes a reverse operation of one or more of a rate-k pre-transform operation, a rate-k post-transform operation, a pre-coding operation, an outer code application, or an inner code application.12.The method (600) of claim 11, wherein receiving the encoded data along with one of the indication of the coding scheme or the application of the pre-processing operation on the coding scheme comprises:receiving, from the transmitter (202), one of the indication of the coding scheme or the application of the pre-processing operation on the coding scheme via at least one of a Radio Resource Control (RRC) configuration message, a medium access control (MAC) control element (CE) message, or a Downlink Control Information (DCI) message.13.The method (600) of claim 11, further comprises:prior to receiving the encoded data along with one of the indication of the coding scheme or application of the pre-processing operation on the coding scheme, transmitting, to the transmitter (202), an indication via one of an Uplink Control Information (UCI) message or a Physical Uplink Shared Channel (PUSCH),wherein the indication is indicative of at least one of a receiver-selected coding scheme or a decision for applying the pre-processing operation on the receiver -selected coding scheme.14.A transmitter (202), comprising:a transceiver; andat least one processor coupled with the transceiver and configured to:apply a pre-processing operation on a coding scheme based on a plurality of parameters, wherein the pre-processing operation includes one or more of a rate-k pre-transform operation, a rate-k post-transform operation, a pre-coding operation, an outer code application, or an inner code application,encode data to be transmitted based on the pre-processed coding scheme, wherein the transmission data includes at least one of user data or control data, andtransmit, to a receiver (204) via a plurality of transmission channels, the encoded data along with one of an indication of the coding scheme or the application of the pre-processing operation on the coding scheme.15.A receiver (204), comprising:a transceiver; andat least one processor coupled with the transceiver and configured to:receive, from a transmitter (202) via a plurality of transmission channels, an encoded data along with one of an indication of a coding scheme or application of a pre-processing operation on the coding scheme, anddecode the received encoded data based on applying a post-processing operation to the coding scheme, wherein the post-processing operation includes a reverse operation of one or more of a rate-k pre-transform operation, a rate-k post-transform operation, a pre-coding operation, an outer code application, or an inner code application.

Images