WO2025148317A1 - Method, device, and system for unified pucch transmission - Google Patents

Abstract

A method, device, and system for wireless communication. One method performed by a wireless device may include: encoding a first input bit sequence c_k using a coder to obtain an output bit sequence d_i, wherein: the first input bit sequence carries a first type UCI, the first type UCI is characterized by that its length is equal to K, and K is equal to 1 or 2; a length of the first input bit sequence equals to K, k being an index of c_k and having a range from 0 to K-1; a length of the output bit sequence equals to N, N being an integer greater than K, i being an index of d_i and having a range from 0 to N-1; and transmitting the output bit sequence or a transformation of the output bit sequence over a wireless communication channel to a wireless communication node.

Description

METHOD, DEVICE, AND SYSTEM FOR UNIFIED PUCCH TRANSMISSION TECHNICAL FIELD

This disclosure is directed generally to wireless communications, and particularly to a method, device, and system for channel coding in a wireless network, such as a 4G, 5G NR, or 6G network.

BACKGROUND

In a wireless communication system, the wireless channel is subjected to various interferences and may lead to data transmission errors. Channel coding is a critical element in data transmission for effectively mitigating wireless channel interferences. Specifically, channel coding may provide following benefits: improved reliability; error detection and correction; higher data rates; improved spectrum efficiency; increased transmission range; and improved energy efficiency.

SUMMARY

This disclosure is directed to a method, device, and system for wireless communication, and more specifically, for channel coding in a wireless network, such as a 4G, 5G NR, or 6G network. The channel coding may include Reed-Muller (RM) code.

In some embodiments, a method performed by a wireless device is disclosed. The method may include: encoding a first input bit sequence c_k using a coder to obtain an output bit sequence d_i, wherein: the first input bit sequence carries a first type Uplink Control Information (UCI) applying to the wireless communication system, the first type UCI is characterized by that its length is equal to K, and K is equal to 1 or 2; a length of the first input bit sequence equals to K, k being an index of c_k and having a range from 0 to K-1; a length of the output bit sequence equals to N, N being an integer greater than K, i being an  index of d_i and having a range from 0 to N-1; and transmitting the output bit sequence or a transformation of the output bit sequence over a wireless communication channel to a wireless communication node.

In some embodiments, another method performed by a wireless device is disclosed. The method may include: extending an input bit sequence b_j to obtain an extended input bit sequence c_k, wherein: the input bit sequence carries an Uplink Control Information (UCI) , the UCI is characterized by its length being equal to J bits, and J is equal to 1 or 2; a length of the input bit sequence b_j is equal to J, j is an index of b_j and has a range from 0 to J-1; a length of the extended input bit sequence c_k is equal to K, K is an integer greater than J, k is an index of c_k and has a range from 0 to K-1; encoding the extended input bit sequence c_k using a coder to obtain an output bit sequence d_i, wherein: a length of the output bit sequence d_i is equal to N, N being an integer greater than K, i is an index of d_i and has a range from 0 to N-1; and in the wireless communication system, the coder is applicable to channel encoding bit sequences longer than or equal to K bits and is not applicable to channel encoding bit sequences less than K bits; and transmitting the output bit sequence or a transformation of the output bit sequence over a wireless communication channel to a wireless communication node.

In some embodiments, there is a UE/wireless device or a wireless network node comprising a processor and a memory, wherein the processor is configured to read code from the memory and implement any methods recited in any of the embodiments.

In some embodiments, a computer program product comprising a computer-readable program medium code stored thereupon, the code, when executed by a processor, causing the processor to implement any method recited in any of the embodiments.

The above embodiments and other aspects and alternatives of their implementations are described in greater detail in the drawings, the descriptions, and the claims below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an example wireless communication network.

FIG. 2 shows an example wireless network node.

FIG. 3 shows an example user equipment.

FIG. 4 shows an exemplary channel coding procedure.

FIG. 5 shows an exemplary generation matrix for channel coding.

FIG. 6 shows another exemplary generation matrix for channel coding.

FIG. 7 shows an example for extending a bit sequence/code block by using a walsh code.

FIGs. 8A-8B show examples for extending a bit sequence/code block by adding dummy bits or additional control information.

FIGs. 8C-8E show various UCI/PUCCH payload structures of extended bit sequence/code block.

DETAILED DESCRIPTION

Wireless Communication Network

FIG. 1 shows an exemplary wireless communication network 100 that includes a core network 110 and a radio access network (RAN) 120. The core network 110 further includes at least one Mobility Management Entity (MME) 112 and/or at least one Access and Mobility Management Function (AMF) . Other functions that may be included in the core network 110 are not shown in FIG. 1. The RAN 120 further includes multiple base stations, for example, base stations 122 and 124. The base stations may include at least one evolved NodeB (eNB) for 4G LTE, an enhanced LTE eNB (ng-eNB) , or a Next generation NodeB (gNB) for 5G New Radio (NR) , 6G network or any other type of signal  transmitting/receiving device such as a UMTS NodeB. The eNB 122 communicates with the MME 112 via an S1 interface. Both the eNB 122 and gNB 124 may connect to the AMF 114 via an Ng interface. Each base station manages and supports at least one cell. For example, the base station gNB 124 may be configured to manage and support cell 1, cell 2, and cell 3.

The gNB 124 may include a central unit (CU) and at least one distributed unit (DU) . The CU and the DU may be co-located in a same location, or they may be split in different locations. The CU and the DU may be connected via an F1 interface. Alternatively, for an eNB which is capable of connecting to the 5G network, it may also be similarly divided into a CU and at least one DU, referred to as ng-eNB-CU and ng-eNB-DU, respectively. The ng-eNB-CU and the ng-eNB-DU may be connected via a W1 interface.

The wireless communication network 100 may include one or more tracking areas. A tracking area may include a set of cells managed by at least one base station. For example, tracking area 1 labeled as 140 includes cell 1, cell 2, and cell 3, and may further include more cells that may be managed by other base stations and not shown in FIG. 1. The wireless communication network 100 may also include at least one UE 160. The UE may select a cell among multiple cells supported by a base station to communication with the base station through Over the Air (OTA) radio communication interfaces and resources, and when the UE 160 travels in the wireless communication network 100, it may reselect a cell for communications. For example, the UE 160 may initially select cell 1 to communicate with base station 124, and it may then reselect cell 2 at certain later time point. The cell selection or reselection by the UE 160 may be based on wireless signal strength/quality in the various cells and other factors.

The wireless communication network 100 may be implemented as, for example, a 2G, 3G, 4G/LTE, 5G, or 6G cellular communication network. Correspondingly, the base stations 122 and 124 may be implemented as a 2G base station, a 3G NodeB, an LTE eNB, a 5G NR gNB, or a 6G base station. The UE 160 may be implemented as mobile or fixed communication devices which are capable of accessing the wireless communication network  100. The UE 160 may include but is not limited to mobile phones, laptop computers, tablets, personal digital assistants, wearable devices, Internet of Things (IoT) devices, MTC/eMTC devices, distributed remote sensor devices, roadside assistant equipment, XR devices, and desktop computers. The UE 160 may also be generally referred to as a wireless communication device, or a wireless terminal. The UE 160 may support sidelink communication to another UE via a PC5 interface.

While the description below focuses on cellular wireless communication systems as shown in FIG. 1, the underlying principles are applicable to other types of wireless communication systems for paging wireless devices. These other wireless systems may include but are not limited to Wi-Fi, Bluetooth, ZigBee, and WiMax networks.

FIG. 2 shows an example of electronic device 200 to implement a network base station (e.g., a radio access network node) , a core network (CN) , and/or an operation and maintenance (OAM) . Optionally in one implementation, the example electronic device 200 may include radio transmitting/receiving (Tx/Rx) circuitry 208 to transmit/receive communication with UEs and/or other base stations. Optionally in one implementation, the electronic device 200 may also include network interface circuitry 209 to communicate the base station with other base stations and/or a core network, e.g., optical or wireline interconnects, Ethernet, and/or other data transmission mediums/protocols. The electronic device 200 may optionally include an input/output (I/O) interface 206 to communicate with an operator or the like.

The electronic device 200 may also include system circuitry 204. System circuitry 204 may include processor (s) 221 and/or memory 222. Memory 222 may include an operating system 224, instructions 226, and parameters 228. Instructions 226 may be configured for the one or more of the processors 221 to perform the functions of the network node. The parameters 228 may include parameters to support execution of the instructions 226. For example, parameters may include network protocol settings, bandwidth parameters, radio frequency mapping assignments, and/or other parameters.

FIG. 3 shows an example of an electronic device to implement a terminal device  300 (for example, a user equipment (UE) ) . The UE 300 may be a mobile device, for example, a smart phone or a mobile communication module disposed in a vehicle. The UE 300 may include a portion or all of the following: communication interfaces 302, a system circuitry 304, an input/output interfaces (I/O) 306, a display circuitry 308, and a storage 309. The display circuitry may include a user interface 310. The system circuitry 304 may include any combination of hardware, software, firmware, or other logic/circuitry. The system circuitry 304 may be implemented, for example, with one or more systems on a chip (SoC) , application specific integrated circuits (ASIC) , discrete analog and digital circuits, and other circuitry. The system circuitry 304 may be a part of the implementation of any desired functionality in the UE 300. In that regard, the system circuitry 304 may include logic that facilitates, as examples, decoding and playing music and video, e.g., MP3, MP4, MPEG, AVI, FLAC, AC3, or WAV decoding and playback; running applications; accepting user inputs; saving and retrieving application data; establishing, maintaining, and terminating cellular phone calls or data connections for, as one example, internet connectivity; establishing, maintaining, and terminating wireless network connections, Bluetooth connections, or other connections; and displaying relevant information on the user interface 310. The user interface 310 and the inputs/output (I/O) interfaces 306 may include a graphical user interface, touch sensitive display, haptic feedback or other haptic output, voice or facial recognition inputs, buttons, switches, speakers and other user interface elements. Additional examples of the I/O interfaces 306 may include microphones, video and still image cameras, temperature sensors, vibration sensors, rotation and orientation sensors, headset and microphone input /output jacks, Universal Serial Bus (USB) connectors, memory card slots, radiation sensors (e.g., IR sensors) , and other types of inputs.

Referring to FIG. 3, the communication interfaces 302 may include a Radio Frequency (RF) transmit (Tx) and receive (Rx) circuitry 316 which handles transmission and reception of signals through one or more antennas 314. The communication interface 302 may include one or more transceivers. The transceivers may be wireless transceivers that include modulation /demodulation circuitry, digital to analog converters (DACs) , shaping tables, analog to digital converters (ADCs) , filters, waveform shapers, filters, pre-amplifiers,  power amplifiers and/or other logic for transmitting and receiving through one or more antennas, or (for some devices) through a physical (e.g., wireline) medium. The transmitted and received signals may adhere to any of a diverse array of formats, protocols, modulations (e.g., QPSK, 16-QAM, 64-QAM, or 256-QAM) , frequency channels, bit rates, and encodings. As one specific example, the communication interfaces 302 may include transceivers that support transmission and reception under the 2G, 3G, BT, WiFi, Universal Mobile Telecommunications System (UMTS) , High Speed Packet Access (HSPA) +, 4G /Long Term Evolution (LTE) , 5G NR, and 6G standards. The techniques described below, however, are applicable to other wireless communications technologies whether arising from the 3rd Generation Partnership Project (3GPP) , GSM Association, 3GPP2, IEEE, or other partnerships or standards bodies.

Referring to FIG. 3, the system circuitry 304 may include one or more processors 321 and memories 322. The memory 322 stores, for example, an operating system 324, instructions 326, and parameters 328. The processor 321 is configured to execute the instructions 326 to carry out desired functionality for the UE 300. The parameters 328 may provide and specify configuration and operating options for the instructions 326. The memory 322 may also store any BT, WiFi, 3G, 4G, 5G, 6G or other data that the UE 300 will send, or has received, through the communication interfaces 302. In various implementations, a system power for the UE 300 may be supplied by a power storage device, such as a battery or a transformer.

PUCCH and UCI in 6G

For 6G, the International Telecom Union (ITU) has released a series of IMT-2030 frameworks and target files for future-oriented IMT-2030 deployment to build an endogenous information society through 6G in order to achieve sustainable development strategies. The goals include inclusion, ubiquitous connectivity, sustainability, innovation, enhanced privacy protection and security, standardization, and interoperability. The applications and services enabled by IMT-2030 expect to connect people, computers, and other different objects. The trend is reflected in: ubiquitous artificial intelligence, ubiquitous computing capabilities,  immersive multimedia and multi-perception interaction, digital twin and virtual world, smart industry, digital health, ubiquitous connection, integrated perception communication, and sustainable development. Air interfaces and wireless networks need to be enhanced. Air interfaces involve enhanced coding technologies. Enhanced waveform design includes orthogonal, biorthogonal and non-orthogonal, non-orthogonal multiple access and grant-free access, E-MIMO, self-interference cancellation technology in full-duplex systems, Reconfigurable Intelligent Surfaces (RIS) , holographic radio, angular momentum communication, below-1THz and 1THz frequency band communication, and ultra-high-accuracy positioning technologies. The technology-enabled wireless network includes the Quality of Service (QoS) guarantee mechanism, deterministic wireless network, convergence-driven RAN architecture, intrinsic Artificial Intelligence (AI) RAN, network node coordination and aggregation, UE-Centered Network (UCN) , digital twin network, interoperability with Non-Terrestrial Network (NTN) , and Ultra-Dense Network UDN.

The new application scenario proposed by IMT-2030 is based on the extension of the three scenarios proposed by IMT-2020, which are described below.

· Immersive Communication: which is extended from the eMBB scenario and includes immersive XR, remote multi-sensory telepresence, and holographic communications. Immersive Communication may provide users with a rich and interactive video experience.

· Hyper Reliable and Low-Latency Communication: This may enhance communications in an industrial environment for full automation, control, and operation. These types of enhanced communications may include fully automated industrial communication, such as robot interaction, emergency services, telemedicine, and power transmission and distribution monitoring.

· Massive Communication: Large-scale communication, which provides extension and new applications in smart cities, transportation, logistics, health, energy, environment monitoring, agriculture, and many other fields, such as IoT devices requiring no battery or long-life batteries.

· Ubiquitous Connectivity: This focuses on areas with no coverage and few coverage. It may bridge the digital divide, especially for rural and remote areas. Typical use cases include  IoT and mobile broadband communication, especially for rural areas.

· Integrated Artificial Intelligence and Communication: These types of communications support auxiliary autonomous driving, autonomous collaboration between devices for medical auxiliary applications, unloading of heavy computing operations across devices and networks, creation and prediction of digital twins, and collaborative robots assisted by IMT-2030.

· Integrated Sensing and Communication: Perception communication. Typical scenarios include auxiliary navigation, activity detection and motion tracking (for example, gesture/gesture recognition, fall detection, and vehicle/pedestrian detection) , environment monitoring (for example, rain/pollution detection) , and sensing data/information about the surrounding environment for AI, XR, and digital twin applications.

The Physical Uplink Control Channel (PUCCH) is an important physical channel for uplink control information transmission. In 5G New Radio (NR) , five PUCCH formats are supported to accommodate different cases/scenarios, e.g., to support different number of Uplink Control Information (UCI) bits, different waveforms, different allocated Resource Blocks (RBs) , different allocated symbols, etc. Table 1 below shows example formats supported in 5G NR.

Table 1: PUCCH Formats in NR

While 6G is expected to support a broader range of applications than 5G, as outlined in the IMT-2030 proposals for new scenarios, it is not anticipated to increase the number of PUCCH formats. On the contrary, there is a trend towards simplification, with the ideal goal being the design of a single, versatile PUCCH format that can accommodate all use cases. The unified PUCCH format, or one PUCCH format that is compatible for  multiple use cases is desired, as this may simplify the PUCCH transmission and make the channel structure more flexible.

In this disclosure, various embodiments are described, aiming to streamline the UCI design and unify PUCCH formats. The goal is to create a versatile UCI format that can be adapted to accommodate a wider range of use cases.

In the wireless communication system such as 5G or 6G, small amount of control information, including the uplink physical layer control information needs to be transmitted through the physical uplink control channel. In the perspective of uplink, the PUCCH is applicable to the transmission of, for example, Acknowledgment/Negative Acknowledgment (ACK/NACK) , Scheduling Request (SR) , periodical or semi-persistent scheduled Channel State Information (CSI) , etc. The size of above information supported by PUCCH is not very large. The minimum size is 1 bit (e.g., for Hybrid Automatic Repeat Request (HARQ) ) , and the maximum size is 1706 bits. Typically, UCI consists of a small number of bits, usually between 1 and a few dozen.

It is challenging to support physical-layer UCI from 1 bit to 1706 bits by a unified channel structure and a unified channel coding. From the current standardization practice and existing technologies, it is hard to achieve a single design that optimally balances complexity, transmission efficiency, and performance in various use scenarios. Therefore, a more practical approach involves making modest, backward-compatible enhancements/extensions to existing channel structures and channel coding, building upon and compatible with established standardization solutions.

In 5G NR, the PUCCH format 1 and format 3 are extensively used in the current network. Format 1 typically handles scenarios requiring 1-2 bits (i.e., the payload of the UCI message is 1-2 bits) , whereas format 3 accommodates scenarios requiring more than 2 bits. Given their widespread use and coverage of most application scenarios, designing a universal PUCCH format based on either format 1 or 3 is a logical approach.

Extending PUCCH format 1 presents significant challenges. This format  modulates reference sequences with information bits and employs time-domain orthogonal code extension, which limits its scalability for larger number of bits (larger payload) . Consequently, developing a general PUCCH format based on format 1 is not considered a viable option.

PUCCH format 3, on the other hand, is a more suitable candidate for developing a unified PUCCH format. Currently, it already supports information payloads larger than 2 bits. The focus would be to enhance or evolve PUCCH format 3 to efficiently accommodate smaller payloads of 1-2 bits as well. This enhancement would enable the extended PUCCH format 3 to transmit UCI currently carried by PUCCH format 1, resulting in a more versatile and comprehensive format.

A typical structure for PUCCH format 3 is shown in FIG. 4.

In FIG. 4, the input UCI information bit sequence 410 is processed by channel coding. The algorithm of channel coding for 3～11 bits UCI is Reed-Muller (RM) coding, whereas for size of UCI larger than 11 bits, Polar coding is used. The coded bits (output bit sequence 412) are scrambled and modulated by, for example, π/2-BPSK (Binary Phase Shift Keying) or QPSK (Quadrature Phase Shift Keying) to form the y symbol (modulation symbol) . The y symbol will be transformed by Discrete Fourier Transform (DFT) and multiplied by a reference sequence r, then mapped to each OFDM data symbols indexed by U. Symbols marked by “R” is the container for the reference signal aiding the demodulation of data.

In some example implementations, 1, 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, and 16 Resource Blocks (RBs) may be selected to match the total number of modulation symbols y.

The input to the channel coding may be denoted as a bit sequence c_k (or sequence for simplicity) with a length of K bits. The input UCI bit sequence may also be referred to as a code block.

In some example implementations, when K, the number of UCI bits to be  transmitted is between 3 and 11, the code block is encoded using an RM coder, as shown in equation below:

where d_i is the output bit sequence (also referred to as a coded block) after channel coding which has a length of N, N=32, i = 0, 1, …, N-1, and M_i, k represents the basis sequences as defined in the table shown in FIG. 5. As shown in FIG. 5, each column (i.e., M_i, 0, M_i, 1, M_i, 2, …, M_i, 10) represents a basis sequence.

Stated another way, the table in FIG. 5 represents a coding matrix or generation matrix. The coding matrix consists of eleven 32-bit basis sequences, labeled M_i, 0, M_i, 1, M_i, 2, through M_i, 10. For simplicity, in this matrix, from left to right, the columns may be denoted as M₀, M₁, M₂, …, M₁₀. For example, as shown in FIG. 5, the first column (column 0) corresponds to basis sequence M₀, while the sixth column (column 5) corresponds to basis sequence M₅.

In some example implementations, as shown in FIG. 5, M₀ is an all-one sequence. M₁ to M₅ are interleaved Walsh sequences. When the Walsh sequences M₁ to M₅ are aligned and linearly combined for BPSK modulation, thirty-two mutually orthogonal sequences may be obtained, that is, a group of orthogonal basis sequences. M₆ to M₁₀ are five basis mask sequences. Thirty-two different mask basic sequences may be determined after linear combination of M₆ to M₁₀ to maximize the code distance.

When 3≤K ≤6, the RM coding based on the table in FIG. 5 falls back to a simple RM (5, 1) coder. That is, following an RM (m, r) notation, m=5, r=1. Note that r indicates the level of the RM code, and r=1 means that the generator polynomial is a level 1 linear combination. “m” is an indicator for code length after the channel coding (code length = 2^m) . The column (s) in FIG. 5 which generates a polynomial is used as a basis sequence. In RM (5, 1) , there are no instances where two or more basis sequences are multiplied to produce another basis sequence. Note that m=5 indicates that the length of  output of coder is 2^m=2^5=32. In the meantime, the minimal code distance is 2^ (m-1) =16.

When 7≤K ≤11, additional mask sequences (i.e., columns from M_i, 6 to M_i, 10) are introduced for encoding. When K=11, the code distance is 10; when 7≤K ≤10, the code distance is 11. When the number of information bit is within 6 (including 6) , the code distance is optimal for coding performance.

Note that in certain notation, RM (m, r) may also be written as RM (r, m) .

Embodiment 1: Extending a PUCCH Format to Support UCI with 1 or 2 Bits

As discussed above, the aim to design a unified PUCCH format is to support 1～2 UCI information bits based on the current existing PUCCH format 3. Current PUCCH format 3 uses the RM coding for 3≤K ≤11 (K is the number of bits in the input UCI bit sequence) . In this embodiment, the usage of RM coder is extended to cover the case when 1≤K ≤2. That is, when 1≤K ≤2, rather than using the non Reed-Muller (non-RM) coding method currently employed in PUCCH format 1, RM coding is chosen, to align with PUCCH format 3.

In some example implementations, for K=1 (UCI only has 1 bit) , the RM coding (5, 0) is used. The generation matrix may include, for example, an all-one sequence x0 = {1 1 ……1 1} , and the length of sequence is 2^5=32.

In some example implementations, for K=2 (UCI has 2 bits) , two base sequences should be selected from an R (5, 1) generation matrix to form a generation matrix dedicated for K=2. More details will be given for the generation matrix. In some example implementations, for the sequence selection, the all-one sequence is excluded.

FIG. 6 shows an example R (5, 1) generation matrix which consists of 6 columns (labeled N₀ through N₅) and 32 rows. Each column may represent a basis sequence for RM coding. When using the RM coder to perform channel coding, one column from FIG. 6 may be selected if K=1, and two columns may be selected if K=2.

Note that the generation matrix shown in FIG. 6 may also be represented, or defined as its transposition matrix. Both the generation matrix and its transposition matrix are covered under this disclosure.

In some example implementations, when K=1, the RM coder may use the first column N₀ as the basis sequence.

In some example implementations, when K=2, the RM coder may select two of the last five columns, N₁ through N₅. In some example implementations, the selection of the two columns may be predefined. In some other example implementations, the selection may be indicated to a UE from a network node (e.g., base station) through signaling which may include, for example, Radio Resource Control (RRC) signaling, Medium Access Control (MAC) signaling, or Downlink Control Information (DCI) .

In some example implementations, when K=2, the first sequence may be fixed to N₀, while the second sequence may be selected from the last five columns, N₁ through N_5.

In some example implementations, the selected sequences (as described above) may be used for channel coding via an RM (5, 1) coder (m=5, r=1) when 1≤K ≤2, this coder may follow the same principle of RM coder used for existing PUCCH format 3 (e.g., in 5G NR) .

In this embodiment, the PUCCH format 3 is extended, to support channel coding for UCI with input size ranging from 1-11 bits, utilizing an RM coder. Note that input size 1-2 bits are not supported by RM coder in existing wireless technologies such as 5G NR. When the UCI input bit sequence (payload) contains 3-11 bits, RM coding using a generation matrix (e.g., table in FIG. 5) currently adopted in the wireless system is used. Whereas when the UCI input bit sequence contains 1-2 bits, a newly introduced generation matrix is employed, and the basis sequence (s) used by RM coding may be selected from this newly introduced generation matrix, for example, the matrix as shown in FIG. 6.

This embodiment may be generalized by the equation below:

Referring to FIG. 4, in this equation, c_k is the input UCI bit sequence 410 with length K (k = 0, 1, …, K-1) bits, K is an integer; d_i is the output bit sequence 412 with length N (i = 0, 1, …N-1) . Exemplarily, N=32.

When 3≤K ≤11, K columns (M_i, k, k from 0 to K-1) are selected from the table in FIG. 5, with each column representing a basis sequence for the RM coding. For example, when K=3, columns Mi_, 0 (also denoted as M₀) , M_i, 1, and M_i, 2 are selected.

In some example implementations, when K = 1, the basis sequence is an all-one sequence {1 1 ……1 1} (shown as column N₀ in FIG. 6) , the length of the all-one sequence is 32. This basis sequence may be denoted as M_i, 0 when applying to the equation above.

In some example implementations, when K = 1, the basis sequence may be selected (as column) from the table shown in FIG. 6.

In some example implementations, when K = 2, one of the basis sequence is column N₀ as shown in FIG. 6, which may also be denoted as M_i, 0. Another basis sequence is selected from the last five columns of FIG. 6 (i.e., N₁ to N₅) , which may be denoted as M_i, 1 when applying to the equation above.

In some example implementations, when the K = 2, the two basis sequences are selected from the last five columns in the table shown in FIG. 6, and the selected two columns may be denoted as M_i, 0, M_i, 1.

In some example implementations, the selection of the column (s) (i.e., basis sequence) may be predefined. In some other example implementations, the selection may be indicated to a UE from a network node (e.g., base station) through signaling which may include, for example, RRC signaling, MAC signaling, or DCI.

In this embodiment, the RM coder is extended, so it may apply to UCI with 1 or 2  bits payload. The underlying principle may also apply to other types of coders, such as polar coder. For example, by extending existing generation matrix, or add a new generation matrix (or basis sequences) .

Embodiment 2: Extending UCI Bits before Channel Coding

As previously discussed, PUCCH format 3 employs an RM coder for UCI payloads (i.e., the input UCI bit sequence) of 3 to 11 bits. In this embodiment, when the UCI payload is only 1 or 2 bits, a pre-processing step is introduced. This step extends, or spreads the UCI bit sequence to create an expanded version containing 3 to 11 bits, making the input UCI bit sequence compatible with the existing RM coding scheme under PUCCH format 3. Specifically, the extended UCI bit sequence may or may carry additional payload information compared to original payload. The payload information may include control information, information element, syntax element, and the like.

Multiple techniques are introduced for expanding the UCI bit sequence, which are described in details below.

Option 1: Extending UCI bits using Walsh code

FIG. 7 shows an example procedure for spreading the UCI bit sequence before the channel coding.

As shown in FIG. 7, the input is a UCI code block (bit sequence) b_j with 1 or 2 bits. The encoding procedure may include following steps:

Step 1: The UCI code block is transformed to a non-return to zero (NRZ) code block, that is, ‘1’ is transformed to ‘+1’ , and ‘0’ is transformed to ‘-1’ , or vice versa.

Step 2: The NRZ code block are multiplied with a Walsh code W_i, with 0≤i≤3 or 0≤i≤7, to output an extended NRZ UCI sequence with K elements, where 3 <= K <= 11. More details will be described for W_i below. The extended NRZ UCI sequence is denoted as b_k and may also be referred to as a code block under NRZ.

The length of the Walsh code is typically 2, 4, 8, 16, …, 2n, where n is an integer. To maintain the extended UCI sequence length between 3 and 11 bits so it can fit in PUCCH format 3, only Walsh codes of length 4 or 8 are suitable. Consequently, Walsh codes of length 4 or 8 will be employed to extend original UCI payload with 1 to 2 UCI bits. Tables 2 and 3 below show example Walsh code with length of 4, and length of 8, respectively.

Table 2: Length 4 Walsh Code

Table 3: Length 8 Walsh Code

In some example implementations, the selection of a particular Walsh code may be predefined or preconfigured for a UE. In some other example implementations, the selection may be indicated by a network node (e.g., base station) to a UE through signaling which may include, for example, RRC signaling, MAC signaling, or DCI. In some other example implementations, the index of the Walsh code used by a UE may be derived based on an identification of the UE. For example, the index may be calculated from a linear transformation of the UE ID.

Step 3: The code block b_k is reversely transformed to return-to-zero (RZ) code and output a bit sequence c_k (also denoted as code block c_k) . The length K of code block c_k is 4 or 8.

Step 4: The code block c_k is encoded by:

Where M_i, k may be based on, for example, the table in FIG. 5, K is number of bits in c_k, and i is from 0 to N-1. Exemplarily, N=32.

As an example, if K=4, then columns M_i, , 0 through M_i, 3 from FIG. 5 may be used in the above equation.

Applying a Walsh code multiplication to the original UCI input sequence can also enhance channel coding efficiency, as more UEs may be multiplexed in one time-frequency resource. If the length of Walsh code is 4, the multiplexing factor is 4. If the length of Walsh code is 8, the multiplexing factor is 8.

Option 2: Using XOR to extend UCI bits

When the initial UCI bit sequence (code block) has 2 bits of c₀ and c₁, the length of code block can be extended to 3 bits by adding a new bit c2 using an XOR (exclusive OR) operation:

whereis the XOR operator.

The extended UCI code block c_k contains c₀, c₁ and c₂ and is encoded via an RM coder using following RM equation:

Where M_i, k is may be based on, for example, the table in FIG. 5, K=3 (there are 3 bits in the extended UCI code block) , and i is from 0 to N-1. Exemplarily, N=32.

When the initial UCI code block has only 1 bit (c₀) , the code block may be multiplied with an all-one sequence x0 = [1 1 ……1 1] , the length of sequence x0 is N. That is, using the RM equation above, K=1, M_i, 0 = x0, and i is from 0 to N-1. Exemplarily, N=32.

Option 3: Extending UCI bits using repetition

In some example implementations, when the initial UCI bit sequence (code block) has 2 bits of c₀ and c₁, the length of code block may be extended to 4 bits by repetition following a repetition pattern. For example, by repeating c₀, c₁, the output extended code block is {c₀, c₁, c₀, c₁} .

In some example implementations, when the initial UCI bit sequence (code block) has 2 bits of c₀ and c₁, the length of code block may be extended to 8 bits by repetition following a repetition pattern. For example, by repeating c₀, c₁, the output extended code block is {c₀, c₁, c₀, c₁, c₀, c₁, c₀, c₁} .

The repetition patterns above are just for exemplary purpose, and other repetition algorithms may be adopted. For example, the repetition output may include: {c₀, c₀, c₁, c₁} , or {c₀, c₀, c₀, c₀, c₁, c₁, c₁, c₁} when using different repetition algorithms.

The extended UCI code block c_k via repetition may then be encoded via an RM coder using following equation:

Where M_i, k is may be based on, for example, the table in FIG. 5, K is number of bits in c_k, and i is from 0 to N-1. Exemplarily, N=32.

When the initial UCI code block has only 1 bit (c₀) , the code block is multiplied with an all-one sequence x0 = [1 1 ……1 1] , the length of sequence x0 is 32. That is, using the equation above, K=1, M_i, 0 = x0, and i is from 0 to N-1. Exemplarily, N=32.

Option 4: Extending UCI bits using convolutional coding

In some example implementations, when the initial UCI bit sequence (code block) has 2 bits of c₀ and c₁, the length of code block may be extended by applying convolutional coding to the initial UCI code block. After the extension, the output extended UCI code block contains n bits, with 3≤n≤11.

The extended UCI code block c_k via repetition may then be encoded via an RM coder, by using following equation:

Where M_i, k is may be based on, for example, the table in FIG. 5, K is number of bits in c_k, and i is from 0 to N-1 with N=31.

When the initial UCI code block has only 1 bit (c₀) , the code block is multiplied with an all-one sequence x0 = [1 1 ……1 1] , the length of sequence x0 is 32. That is, using the equation above, K=1, M_i, 0 = x0, and i is from 0 to N-1. Exemplarily, N=32.

Option 5: Extending UCI bits using lookup table

In some example implementations, when the initial UCI bit sequence (code block) has 2 bits of c₀ and c₁, the length of code block may be extended to n bits by using a lookup table, where 3≤n≤11.

An exemplary lookup table may be defined as following. The left side is the original UCI bit sequence, and the right side is the mapped bit sequence.

· 00 → 00011011

· 01 → 00110101

· 10 → 01010110

· 11 → 01101001

In some example implementations, the lookup table may be predefined or preconfigured for a UE. In some other example implementations, the selection may be indicated by a network node (e.g., base station) to a UE through signaling which may include, for example, RRC signaling, MAC signaling, or DCI.

When the initial UCI code block has only 1 bit (c₀) , the code block is multiplied with an all-one sequence x0 = [1 1 ……1 1] , the length of sequence x0 is 32. That is, using the equation above, K=1, M_i, 0 = x0, and i is from 0 to N-1. Exemplarily, N=32.

Option 6: Extend to multi-purpose UCI

A wireless system such as LTE and 5G NR may support a wide range of spectrum across different frequency ranges. In 5G NR, the spectrum blocks in the low frequency range of FR1 (Frequency Range 1) bands are currently fragmented and scattered, while there are higher bandwidths and more available spectrum blocks in the high frequency range of the FR1 bands, as well as in the FR2 (Frequency Range 2) and FR3 (Frequency Range 3) bands. In WRC-23 (World Radio communications Conference 23) , 6425-7125 MHz has been identified to IMT (International Mobile Telecommunications) and could be a promising band for 6G at early stage. Additionally, new centimeter wave spectrums including 4.4-4.8 GHz, 7.125-8.4 GHz and 14.8-15.35 GHz may also be assigned to IMT. The allocation of new frequency bands, together with the re-farming of spectrum used for previous generations of cellular networks, is anticipated to result in a growing availability of spectrum resources in the market for 6G deployment.

Multi-carrier operation has been a key for operators to flexibly utilize different spectrum blocks across different frequency ranges. To meet different spectrum needs of operators in different regions, it is important to ensure a unified, flexible and efficient utilization of the available spectrum. It is desirable to support multi-carrier operation as a benchmark for 6G. For example, multi-carrier, rather than single carrier, may be set as default mode in 6G. The shift from a single-carrier to a multi-carrier default configuration may significantly influence the design of the PUCCH. This change necessitates that the  PUCCH be designed with multi-carrier operations as a primary consideration, regardless of whether the multi-carrier operation is Carrier Aggregation (CA) based or non-CA based.

When operating in multi-carrier operation mode, the PUCCH associated with multiple Downlink (DL) carrier needs to carry much more UCI bits compared with a single carrier operation, as the PUCCH needs to convey feedback for a greater number of DL carriers. Therefore, in 6G, the existing NR PUCCH format that supports more than 2 UCI bits is inherently well-suited for natively supporting multi-carrier operation. In future network deployments such a s 6G, it is anticipated that PUCCH formats capable of carrying more than 2 UCI bits, such as the NR PUCCH format 3, will become predominant. This shift is at least due to the increasing data volume in UCI that needs to be transmitted (e.g., due to multi-carrier operation as default in 6G) . Conversely, PUCCH formats limited to supporting only one or two bits may become obsolete and potentially phased out.

When using multi-carrier as default operation, a PUCCH format (and its corresponding channel coding method) , such as a format identical or similar to the existing NR PUCCH format 3, may be defined/selected to support more than 2 UCI bits. Such a PUCCH format may be referred to as a basis format, or a default format. The construction of this format has payload capacity of more than 2 bits.

While the PUCCH format supporting multiple carriers will serve as the basis or default format, a fallback mechanism for falling back to single carrier should still be considered. This consideration is important for several reasons:

1. Device Compatibility: Some UE may have limited capability and only support a single carrier due to, for example, hardware limitations or design constraints.

2. Sufficient Capacity: In certain scenarios, a single carrier may provide adequate service capacity to meet the user's needs, making multi-carrier operation unnecessary.

3. Flexibility: Maintaining single-carrier compatibility ensures the network can adapt to various deployment scenarios and user requirements.

4. Backwards Compatibility: This approach allows for seamless integration with legacy devices or in deployments where multi-carrier infrastructure is not yet available.

5. Energy Efficiency: Single-carrier operation may be more power-efficient for certain use cases or device types.

Further, the fallback mechanism for PUCCH format should be considered in the framework of virtual multiple carriers. This means that even though actually used DL carrier is only one, the signaling structure of PUCCH inherits the PUCCH framework of multiple carriers and a single carrier is still viewed as virtual multiple carriers. From a payload perspective, the payload for the particular PUCCH format is fixed –whether the UCI (using the particular PUCCH format) is for multi-carrier or single carrier.

Assuming, as a baseline, that at least two DL carriers need to be supported, with a corresponding UCI payload size of n bits, where n is at least 4. Under these conditions, the NR PUCCH format 3 or formats 2/4 would be appropriate choices. However, in scenarios where carrier fallback or sinking occurs (i.e., reverting to fewer carriers or single-carrier operation) , the actual number of UCI bits that need to transmitted may decrease to 2 or fewer. As the designed payload of the UCI is fixed to n or fixed to a range (e.g., for PUCCH format 3, it’s 3-11 bits) , UCI bits extension or spreading is needed to meet the required number of UCI bits.

Various approaches are described below for extending the UCI bits.

In some example implementations, when the actual payload size is less than the designed capacity n (e.g., due to multi-carrier fallback) , dummy bits may be employed to fill the gap. The dummy bits may include undefined information bits, or predefined bits. For example, these dummy bits may be all one, all zero, or defined by a lookup table. Compared with real payload that carries meaningful uplink control information, these dummy bits are used to fill up the gap between real payload and the PUCCH (UCI) capacity. Therefore, they may be considered as “faked payload” . This approach allows the wireless system to maintain a consistent payload size of n bits, even when multiple carriers fall back  to a single carrier, resulting in fewer than n actual UCI bits. An illustration of this approach can be found in FIG. 8A, where the combination of real control information and dummy bits occupies the full n-bit capacity of the UCI.

In some example implementations, rather than extending the UCI bit sequence by adding dummy bits, useful/meaningful control information may be added. For example, the index of the actually accessed/received DL carrier may be added to the UCI, which may indicate to network (e.g., base station) about which DL carrier is being utilized after the fallback occurs. Furthermore, the indication of the fallback DL carrier index can naturally support dynamic DL carrier switching and there is no need to configure the DL service carrier to a UE. For example, the UE User may autonomously judge/measure the status of service in each DL carrier, when one carrier is empty and no service can be seen, the UE will dynamic switch or fallback to the carrier that actually has service transmitted, and indicate to the network about the DL carrier selection by including the chosen DL carrier’s index in the UCI. An illustration of this approach can be found in FIG. 8B, where the combination of initial control information bits 810 and added control information bits (filler bits) 812 occupies the full n-bit capacity of the UCI.

Note that added control information 812 may belong to a different category, or a different type compared with the initial control information 810. Further, added control information 812 and initial control information 810 may be un-related.

In some example implementations, the UCI bit sequence may be extended by adding a request for multiple DL carriers. This feature is particularly useful in scenarios where the wireless system has initially fallen back from multi-carrier to single-carrier operation, then the UE experiences an increased need for service capacity. In such case, the UE may initiate a request to revert to multiple carrier transmissions. This request may be accommodated by incorporating additional signaling bits into the UCI, alongside the original uplink control information.

In some example implementations, as filler bits are added on top of the original  UCI information bits, a UCI message may serve multiple purposes, and an indicator may be added, to indicate or clarify the purpose of the filler bits. This indicator serves to inform the network about the specific function of the filler bits. For example, the indicator may indicate to the network that the filler bits are for DL carrier index, or the filler bits are for additional carrier request. Exemplarily, this indicator may be positioned in from of the filler bits, as shown in FIG. 8C.

In some example implementations, the filler bits may form multiple groups (or sections, segments) , with each group carrying information for its respective purpose. FIG. 8D shows an example, where the filler bits form two groups serving purpose 1 and purpose 2, respectively. An indicator associated with each group is also added, to indicate the purpose, or function of its respective group. The indicator may be referred to as a function indicator, or a purpose indicator. In a payload structure as shown in FIG. 8D, the two indicators are added first, followed by the two groups for control information. In some example implementations, in the first purpose indicator, there is a flag indicating whether additional purpose indicator (such as filler bits purpose #2 indicator) exists or not.

FIG. 8E shows an alternative payload structure with UCI bits extension, where each indicator and its corresponding group are bound together. In some example implementations, in the first purpose indicator, there is a flag indicating whether additional purpose indicator (such as filler bits purpose #2 indicator) exists or not.

Option 7: Extending UCI bits using Pseudo-Noise (PN) sequence

When the UCI code block has 2 bits of c₀ and c₁, the length of code block can be extended by block coding to n bits, and 3≤n≤11. And the extension can be achieved by a longer PN sequence.

For example, the PN sequence, also known as an m-sequence, has a length of 8. One possible generation method for generating the m-sequence may be:
x (n+8) = (x (n+3) +x (n) ) mod2

and sequence may be initialized with x (0) =1, x (n) =0, n=1, 2, …, 7.

The UCI code block containing c₀ and c₁ will firstly repeat 4 times as c= {c₀, c₁, c₀, c₁, c₀, c₁, c₀, c₁} , then the extension by the m-sequence is handled by  is the extended UCI bit sequence.

When the UCI code block only has 1 bit of c₀, the code block is multiplied with all-one sequence x0 = [1 1 ……1 1] , the length of sequence x0 is 32.

In this embodiment, an original UCI input sequence is extended via various methods, so the extended UCI bit sequence may be channel coded by an RM coder. Note that the RM coder is use for exemplary purpose only, and the underlying principle may apply to other types of coders, such as a polar coder.

Embodiment 3: Reusing Existing RM Coder Matrix

In existing technology, when K, size of UCI bits, is between 3 and 11, the code block may be channel encoded by:

Where M_i, k may be based on, for example, the table in FIG. 5, and i is from 0 to N-1. Exemplarily, N=32. Note that currently this table does not apply to the case when K is 1 or 2.

In this embodiment, when size of UCI bits (input bit sequence) is 1 or 2 bits, the table in FIG. 5 may still be used for locating the basis sequence (s) . That is, for K = 1 or K =2, the above equation can be used along with the table in FIG. 5.

In some example implementations, when K=1, column 0 (M_i, 0) may be selected to be used in the above equation. The output may then be an all-one or all-zero sequence with length 32; when K=2, columns 0 and 1 (i.e., M_i, 0 and M_i, 1) from the table in FIG. 5 may be  selected to be used in the above equation, and the channel coding output is a linear combination from the first two columns of the table in FIG. 5, with the coefficients of this linear combination being the original information bits.

Embodiment 4: Coexistence of Legacy PUCCH Format and Unified PUCCH Format

In this embodiment, backward compatibility for a UE is considered. Specifically, a legacy UE may only support legacy PUCCH format, and an enhanced UE may support unified PUCCH format.

In some example implementations, during the initial access stage such as a random access stage, a UE may transmit a PUCCH support indication in Physical Random Access Channel (PRACH) resources, to indicate to the network (e.g., base station) about its capability on supporting PUCCH format (s) , and then the network may configure the UE to transmit the PUCCH with suitable format (e.g., unified PUCCH format) in the following steps. The indication of capability may be implicit. For example, the capability may be implicitly indicated via the RACH (Random Access Channel) resource partitioning, or a particular RACH resource that the UE uses for the random access procedure. The resource may include frequency domain resource, such as a frequency, a frequency range, a Resource Block (RB) , a Resource Element (RE) , a sub carrier spacing (SCS) , or a Band Width Part (BWP) of the RACH resource the UE selects or assigned for performing the random access procedure. The resource may also include time domain resource, such as a frame, a super frame, a slot, a mini-slot, a symbol the UE selects or assigned for performing the random access procedure. The resource may also include code domain resource (s) . The capability may also be explicitly indicated via, for example, a RACH message, or another type of message.

In some example implementations, in the connected state (e.g., RRC connected state) , the UE may report its capability supporting PUCCH format through, for example, RRC signaling, and then the network may configure the UE to transmit the PUCCH with suitable format, such as the unified PUCCH format.

In some example implementations, an enhanced UE may also support some of the legacy PUCCH formats, e.g., PUCCH format 0. Exemplarily, in the initial access stage, the UE may transmit the PUCCH format 0, to finish the access procedure. And the initial access procedure may be the same as a legacy procedure. Once in the RRC connected state, the UE may switch to the unified PUCCH format based on, for example, a network configuration.

In this disclosure, channel coding, especially for uplink, the PUCCH format or structure is unified or streamlined. RM coder, which is currently utilized for channel encoding UCI with payload larger than 2 bits, are extended to support UCI with 1 or 2 bits. By using one unified coder, such as the RM coder, instead of treating/coding UCI with 1 or 2 bits differently, the need for separate coding methods for handling smaller payloads is eliminated, and significant savings and efficiencies can be achieved across software, hardware, and firmware implementations in wireless communication systems.

A method according to embodiments in this disclosure includes a portion or all of the following steps: step 1: encoding a first input bit sequence ck using a coder to obtain an output bit sequence di, wherein: the first input bit sequence carries a first type Uplink Control Information (UCI) applying to the wireless communication system, the first type UCI is characterized by that its length is equal to K, and K is equal to 1 or 2; a length of the first input bit sequence equals to K, k being an index of ck and having a range from 0 to K-1; a length of the output bit sequence equals to N, N being an integer greater than K, i being an index of di and having a range from 0 to N-1; and step 2: transmitting the output bit sequence or a transformation of the output bit sequence over a wireless communication channel to a wireless communication node.

In any portion or combination of the implementations above, the coder is a Reed-Muller (RM) coder.

In any portion or combination of the implementations above, the coder is an RM coder, denoted as RM (5, 1) using an RM (m, r) notation, where r is a level of the RM coder,  and N = 2^m.

In any portion or combination of the implementations above, the coder is of a same type as a coder for encoding a second input bit sequence carrying a second type UCI applying to the wireless communication system, wherein the second type UCI is characterized by that its length is from 3 to 11, inclusive.

In any portion or combination of the implementations above, encoding the first input bit sequence comprises encoding the first input bit sequence using the coder based on a following equation:

wherein M is a matrix, and each column of M, denoted as M_i, 0, M_i, 1, M_i, 2, …, M_i, K-1, is a basis sequence.

Another method according to embodiments in this disclosure includes a portion or all of the following steps: step 1: extending an input bit sequence bj to obtain an extended input bit sequence ck, wherein: the input bit sequence carries an Uplink Control Information (UCI) , the UCI is characterized by its length being equal to J bits, and J is equal to 1 or 2; a length of the input bit sequence bj is equal to J, j is an index of bj and has a range from 0 to J-1; a length of the extended input bit sequence ck is equal to K, K is an integer greater than J, k is an index of ck and has a range from 0 to K-1; step 2: encoding the extended input bit sequence ck using a coder to obtain an output bit sequence di, wherein: a length of the output bit sequence di is equal to N, N being an integer greater than K, i is an index of di and has a range from 0 to N-1; and in the wireless communication system, the coder is applicable to channel encoding bit sequences longer than or equal to K bits and is not applicable to channel encoding bit sequences less than K bits; and step 3: transmitting the output bit sequence or a transformation of the output bit sequence over a wireless communication channel to a wireless communication node.

In any portion or combination of the implementations above, the UCI is  transmitted in a Physical Uplink Control Channel (PUCCH) of the wireless communication system.

In any portion or combination of the implementations above, the coder is a Reed-Muller (RM) coder.

In any portion or combination of the implementations above, encoding the extended input bit sequence ck comprises encoding the extended input bit sequence ck using the coder based on a following equation:

where M is a matrix, and each column of M, denoted as Mi, 0, Mi, 1, Mi, 2, …, Mi, K-1, is a one of: a basis sequence; or a mask sequence.

In any portion or combination of the implementations above, in the wireless communication system, the coder is applicable to channel encoding bit sequences with length equal to K bits and is not applicable to channel encoding bit sequences less than 3 bits.

In any portion or combination of the implementations above, 3<=K<=11.

The embodiments are in this disclosure are described for example purpose, and may be combined to form a new embodiment, if there is no conflict. A single embodiment may also be implemented as multiple sub-embodiments, with each sub-embodiment being considered as a complete embodiment.

The description and accompanying drawings above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other  things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment/implementation” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment/implementation” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.

In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and/or, ” as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a, ” “an, ” or “the, ” may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for the existence of additional factors not necessarily expressly described, again, depending at least in part on context.

Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather,  language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.

Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present solution may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present solution.

Claims (44)

1. A method for wireless communication in a wireless communication system, performed by a wireless device, the method comprising:

   encoding a first input bit sequence c_k using a coder to obtain an output bit sequence d_i, wherein:

   the first input bit sequence carries a first type Uplink Control Information (UCI) applying to the wireless communication system, the first type UCI is characterized by that its length is equal to K, and K is equal to 1 or 2;

   a length of the first input bit sequence equals to K, k being an index of c_k and having a range from 0 to K-1;

   a length of the output bit sequence equals to N, N being an integer greater than K, i being an index of d_i and having a range from 0 to N-1; and

   transmitting the output bit sequence or a transformation of the output bit sequence over a wireless communication channel to a wireless communication node.
2. The method of claim 1, wherein the coder is a Reed-Muller (RM) coder.
3. The method of claim 1, wherein the coder is an RM coder, denoted as RM (5, 1) using an RM (m, r) notation, where r is a level of the RM coder, and N = 2^m.
4. The method of claim 1, wherein the coder is of a same type as a coder for encoding a second input bit sequence carrying a second type UCI applying to the wireless communication system, wherein the second type UCI is characterized by that its length is from 3 to 11, inclusive.
5. The method of any one of claims 1-4, wherein encoding the first input bit sequence comprises encoding the first input bit sequence using the coder based on a following equation:
   

   wherein M is a matrix, and each column of M, denoted as M_i, 0, M_i, 1, M_i, 2, …, M_i, K-1, is a basis sequence.
6. The method of claim 5, wherein following conditions are satisfied:

   K being equal to 1;

   N being equal to 32; and

   basis sequence M_i, 0 being a sequence of all 1 with a length of 32.
7. The method of claim 5, wherein following conditions are satisfied:

   K being equal to 2;

   N being equal to 32; and

   basis sequence M_i, 1 being selected from one of following 5 sequences:

   sequence 1: {0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1} ;

   sequence 2: {0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1} ;

   sequence 3: {0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 1, 1, 1, 1} ;

   sequence 4: {0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1} ; and

   sequence 5: {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1} .
8. The method of claim 7, wherein basis sequence M_i, 0 is characterized by one of:

   basis sequence M_i, 0 being a sequence of all 1 with a length of 32; or

   basis sequence M_i, 0 being selected from one of the sequence 1 to the sequence 5 and being different from the basis sequence M_i, 1.
9. The method of any one of claims 7-8, wherein a selection of at least one of the basis sequence M_i, 0 and the basis sequence M_i, 1 is based on at least one of:

   a pre-defined configuration; or

   an indication from a signaling sent from the wireless communication node, the signaling comprising at least one of: a Radio Resource Control (RRC) signaling, a Medium Access Control (MAC) signaling, or a Downlink Control Information (DCI) .
10. The method of claim 5, wherein following conditions are satisfied:

    K being equal to 2;

    N being equal to 32;

    basis sequence M_i, 0 being a sequence of all 1 with a length of 32; and

    basis sequence M_i, 1 being equal to: {1, 1, 0, 0, 1, 1, 0, 0, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 1, 0, 0, 1, 0, 1, 1, 1, 0, 1, 0, 0, 1, 0} .
11. The method of claim 4, further comprising:

    transmitting, to the wireless communication node, an indication indicating whether the wireless device supporting transmitting the first type UCI and the second type UCI using a coder of same type.
12. A method for wireless communication in a wireless communication system, performed by a wireless device, the method comprising:

    extending an input bit sequence b_j to obtain an extended input bit sequence c_k, wherein:

    the input bit sequence carries an Uplink Control Information (UCI) , the UCI is characterized by its length being equal to J bits, and J is equal to 1 or 2;

    a length of the input bit sequence b_j is equal to J, j is an index of b_j and has a range from 0 to J-1;

    a length of the extended input bit sequence c_k is equal to K, K is an integer greater than J, k is an index of c_k and has a range from 0 to K-1;

    encoding the extended input bit sequence c_k using a coder to obtain an output bit sequence d_i, wherein:

    a length of the output bit sequence d_i is equal to N, N being an integer greater than K, i is an index of d_i and has a range from 0 to N-1; and

    in the wireless communication system, the coder is applicable to channel encoding bit sequences longer than or equal to K bits and is not applicable to channel encoding bit sequences less than K bits; and

    transmitting the output bit sequence or a transformation of the output bit sequence over a wireless communication channel to a wireless communication node.
13. The method of claim 12, wherein the UCI is transmitted in a Physical Uplink Control Channel (PUCCH) of the wireless communication system.
14. The method of claim 12, wherein the coder is a Reed-Muller (RM) coder.
15. The method of claim 14, wherein encoding the extended input bit sequence c_k comprises encoding the extended input bit sequence c_k using the coder based on a following equation:
    

    where M is a matrix, and each column of M, denoted as M_i, 0, M_i, 1, M_i, 2, …, M_i, K-1, is a one of: a basis sequence; or a mask sequence.
16. The method of claim 14, wherein, in the wireless communication system, the coder is applicable to channel encoding bit sequences with length equal to K bits and is not applicable to channel encoding bit sequences less than 3 bits.
17. The method of claim 16, wherein 3<=K<=11.
18. The method of any one of claims 12-17, wherein extending the input bit sequence b_j comprises:

    multiplying the input bit sequence b_j or a transformation of b_j with a Walsh code sequence, to obtain the extended input bit sequence c_k.
19. The method of claim 18, wherein the Walsh code sequence is selected from one of following Walsh code sequences:

    W0: {+1, +1, +1, +1} ;

    W1: {+1, +1, -1, -1} ;

    W2: {+1, -1, +1, -1} ; and

    W3: {+1, -1, -1, +1} .
20. The method of claim 18, wherein the Walsh code sequence is selected from one of following Walsh code sequences:

    w0: {+1, +1, +1, +1, +1, +1, +1, +1} ;

    w1: {+1, +1, -1, -1, +1, +1, -1, -1} ;

    w2: {+1, -1, +1, -1, +1, -1, +1, -1} ;

    w3: {+1, -1, -1, +1, +1, -1, -1, +1} ;

    w4: {+1, +1, +1, +1, -1, -1, -1, -1} ;

    w5: {+1, +1, -1, -1, -1, -1, +1, +1} ;

    w6: {+1, -1, +1, -1, -1, +1, -1, +1} ; and

    w7: {+1, -1, -1, +1, -1, +1, +1, -1} .
21. The method of any one of claims 19-20, wherein a selection of the Walsh code sequence is based on at least one of:

    a pre-defined configuration;

    an indication from a signaling sent from the wireless communication node, the signaling comprising at least one of: a Radio Resource Control (RRC) signaling, a Medium Access Control (MAC) signaling, or a Downlink Control Information (DCI) ;

    an identification of the wireless device; or

    a linear transformation of the identification of the wireless device.
22. The method of claim 18, wherein the transformation of b_j comprises a transformation of c_k to a Non-Return to Zero (NRZ) format.
23. The method of any one of claims 12-17, wherein J equals to 2, and wherein extending the input bit sequence b_j comprises:

    deriving a new element b2 based on: mod 2, whereinis an exclusive OR (XOR) operation, and mod is modulo operation; and

    deriving the extended input bit sequence c_k as: {b0, b1, b2} .
24. The method of any one of claims 12-17, wherein J equals to 2, and wherein extending the input bit sequence b_j comprises:

    extending the input bit sequence b_j by repeating elements in b_j following a repetition pattern, to obtain the extended input bit sequence c_k.
25. The method of claim 24, wherein, based on the repetition pattern, the resulting extended input bit sequence c_k comprises at least one of:

    {b0, b1, b0, b1} ;

    {b0, b1, b0, b1, b0, b1, b0, b1} ;

    {b0, b0, b1, b1} ; or

    {b0, b0, b0, b0, b1, b1, b1, b1} .
26. The method of any one of claims 12-17, wherein J equals to 2, and wherein extending the input bit sequence b_j comprises:

    applying a convolutional coding to the input bit sequence b_j, wherein an input to the convolutional coding is the input bit sequence b_j, and an output of the convolutional coding is  the extended input bit sequence c_k.
27. The method of any one of claims 12-17, wherein K equals to 2, and wherein extending the input bit sequence b_j comprises:

    mapping the input bit sequence b_j to the extended input bit sequence c_k using a lookup table.
28. The method of claim 27, wherein the lookup table comprises following mappings from an input bit sequence to an output bit sequence:

    00 → 00011011;

    01 → 00110101;

    10 → 01010110; and

    11 → 01101001.
29. The method of any one of claims 12-17, wherein extending the input bit sequence b_j comprises extending the input bit sequence b_j by using a Pseudo-Noise (PN) sequence x.
30. The method of claim 29, wherein:

    a length of the PN sequence x is 8;

    the PN sequence x is generated by using following equation: x (n+8) =(x (n+3) +x (n) )mod2; and

    the PN sequence x is initialized with x (0) =1, x (n) =0, n=1, 2, …, 7.
31. The method of any one of claims 12-17, wherein extending the input bit sequence b_j comprises at least one of:

    inserting dummy bits to the input bit sequence b_j, to obtain extended input bit sequence c_k; or

    inserting additional payload information bits to the input bit sequence b_j, to obtain extended input bit sequence c_k.
32. The method of claim 31, wherein inserting the additional payload information bits to the input bit sequence b_j comprises:

    inserting following to the input bit sequence b_j: 1) a function indicator indicating a purpose or a function of the additional payload information bits; and 2) the additional payload information bits.
33. The method of claim 31, wherein:

    the additional payload information bits comprise at least two subsections; and

    a respective function indicator indicating a purpose or a function of each of the at least two subsections is also inserted to the input bit sequence b_j.
34. The method of claim 31, wherein the additional payload information bits and original payload information bits in the input bit sequence b_j provide different types of uplink control information.
35. The method of claim 34, where the additional payload information bits indicate at least one of:

    a downlink carrier that the wireless device selects after a fallback from multiple carriers to single carrier; or

    a request for additional carriers; or

    a request for operating in multiple carrier mode.
36. The method of any one of claims 31-35, wherein the input bit sequence b_j is designated to a PUCCH format which has more capacity than a size of the input bit sequence b_j.
37. The method of claim 36, wherein the UCI carried in the input bit sequence b_j is associated with multi-carrier feature, and wherein a fallback to single carrier or a fallback to less carriers causing a designated PUCCH carrying the input bit sequence b_j having more capacity than the size of the input bit sequence b_j.
38. The method of any one of claims 31-35, wherein:

    the input bit sequence b_j is designated to a PUCCH format which has more capacity than a size of the input bit sequence b_j; and

    the PUCCH format is a designated format for supporting multiple downlink carriers mode which is a default mode in the wireless communication system.
39. The method of claim 38, wherein a length of the input bit sequence b_j being less than a minimum capacity supported the PUCCH format is due to the wireless device falling back from a multiple carriers mode to a single carrier mode.
40. The method of any one of claims 12-17, further comprising:

    transmitting, to the wireless communication node, an indication indicating whether the wireless device supporting transmitting a first type UCI and a second type UCI using a code of same type, wherein the first type UCI has J bits and the second type UCI has K bits.
41. The method of claim 40, wherein transmitting the indication comprises at least one of:

    transmitting the indication during an initial access stage, using a Physical Random Access Channel (PRACH) resource; or

    transmitting the indication when the wireless device is in a connected state via a message.
42. The method of claim 40, further comprising:

    receiving a configuration from the wireless communication node, wherein the configuration indicating whether to use a same PUCCH format to transmit the first type UCI and the second type UCI.
43. A device for wireless communication comprising a memory for storing computer instructions and a processor in communication with the memory, wherein, when the processor executes the computer instructions, the processor is configured to implement a method in any one of claims 1-42.
44. A computer program product comprising a non-transitory computer-readable program medium with computer code stored thereupon, the computer code, when executed by one or more processors, causing the one or more processors to implement a method of any one of claims 1-42.