Implementation and evaluation of Polar Codes in 5G
Implementation och evaluering av Polar Codes för 5G
Tobias Rosenqvist Joël Sloof
Faculty of Health, Science and Technology Computer Science 15 hp Supervisor: Stefan Alfredsson Examiner: Kerstin Andersson Date: 2019-06-12 Serial number: N/A
Implementation and evaluation of Polar Codes in 5G
Tobias Rosenqvist, Joël Sloof
© 2019 The author(s) and Karlstad University
This report is submitted in partial fulfillment of the requirements for the Bachelor’s degree in Computer Science. All material in this report which is not our own work has been identified and no material is included for which a degree has previously been conferred.
Tobias Rosenqvist
Joël Sloof
Approved, Date of defense
Advisor: Stefan Alfredsson
Examiner: Kerstin Andersson
iii
Abstract
In today’s society the ability to communicate with one another has grown, were a lot of focus is aimed towards speed in the telecommunication industry. For transmissions to become even faster, there are many ways to enhance transmission speeds of which error correction is one. Padding messages such that they are protected from noise, while using as few bits as possible and ensuring safe transmit is handled by error correction codes. Short codes with low complexity is a solution to faster transmission speeds. An error correction code which has gained a lot of attention since its first appearance in 2009 is Polar Codes. Polar Codes was chosen as the 3GPP standard for 5G control channel. The goal of the thesis is to develop and implement Polar Codes and rate matching according to the 3GPP standard 38.212. Polar Codes are then to be evaluated with different block sizes and rate matching settings. Finally Polar Code is compared with Convolutional code in a LTE-simulation environment. The performance evaluations are presented using
BLER/(Eb/N0)-graphs. In this thesis a Polar encoder, rate matching and a Polar decoder (with Successive Can- cellation algorithm) were successfully implemented. The simulation results show that Polar Codes performs better with longer block sizes and also has a better BLER-performance than Convolutional Codes when given the same message lengths.
v Contents
1 Introduction 1 1.1 Thesis goal ...... 2 1.2 Results ...... 3 1.2.1 Expected results ...... 3 1.2.2 Actual results ...... 3 1.3 Thesis outline ...... 3
2 Background 4 2.1 Introduction ...... 4 2.2 Mobile broadband ...... 5 2.2.1 Long Term Evolution ...... 5 2.2.2 New Radio ...... 5 2.3 Noise channels ...... 6 2.3.1 AWGN ...... 7 2.4 Phase-shift keying ...... 8 2.5 Channel capacity ...... 9 2.6 Interleaving ...... 9 2.7 Rate matching ...... 9 2.8 Error correction code ...... 10 2.8.1 Convolutional Codes ...... 10 2.8.2 Polar Codes ...... 11
2.9 Eb/N0 ...... 11 2.10 Block error rate ...... 11 2.11 MATLAB ...... 12 2.12 Summary ...... 12
vi 3 Project Design 13 3.1 Introduction ...... 13 3.2 Convolutional Codes ...... 14 3.3 Polar encoder ...... 15 3.3.1 3GPP 38.212 ...... 15 3.3.2 Encoding and channel polarisation ...... 16 3.4 Rate matching ...... 19 3.4.1 Sub-block interleaving ...... 19 3.4.2 Bit selection ...... 20 3.5 Rate dematching ...... 21 3.5.1 Bit deselection ...... 21 3.5.2 Sub-block deinterleaving ...... 22 3.6 Polar decode ...... 22 3.6.1 Belief ...... 23 3.6.2 Frozen bits ...... 23 3.7 Successive Cancellation ...... 24 3.7.1 Leaf state ...... 25 3.7.2 Left state ...... 26 3.7.3 Right state ...... 26 3.7.4 Up state ...... 27 3.8 Simulation ...... 27 3.8.1 Parameters ...... 28 3.8.2 Performance comparisons ...... 29 3.9 Summary ...... 29
4 Project Implementation 30 4.1 Introduction ...... 30 4.2 Convolutional Codes ...... 30
vii 4.3 Polar encoder ...... 30 4.3.1 encode_polar.m ...... 31 4.3.2 getReliabilitySeq.m ...... 33 4.3.3 PolarEncode.m ...... 33 4.3.4 getGn.m ...... 34 4.4 Rate matching ...... 35 4.4.1 rateMatch_polar.m ...... 35 4.4.2 subBlock_interleaver.m ...... 36 4.4.3 bit_selection.m ...... 37 4.4.4 bit_interleaving.m ...... 37 4.5 Rate dematching ...... 38 4.5.1 DerateMatch_polar.m ...... 39 4.5.2 bit_Deinterleaving.m ...... 40 4.5.3 bit_Deselection.m ...... 40 4.5.4 subBlock_Deinterleaver.m ...... 41 4.6 Polar decoder: Successive Cancellation ...... 42 4.6.1 decode_polar.m ...... 43 4.6.2 SC_Decode.m ...... 45 4.6.3 SC_Decode_Node.m ...... 46 4.7 Simulation ...... 48 4.8 Summary ...... 50
5 Results 51 5.1 Introduction ...... 51 5.2 Polar Codes: Successive Cancellation performance ...... 51 5.3 Rate matching with repetition ...... 52 5.4 Rate matching with puncturing ...... 54 5.5 Rate matching with shortening ...... 55
viii 5.6 Polar Codes vs Convolutional Codes ...... 56 5.7 Summary ...... 58
6 Conclusion 59 6.1 Introduction ...... 59 6.2 Thesis evaluation ...... 59 6.3 Future work ...... 60
ix List of Figures
2.1 Effect of AWGN on a Signal of5 dB ...... 7 2.2 Constellation diagram of 8-PSK (left) and BPSK (right) ...... 8 3.1 Simulation chain ...... 13 3.2 Convolutional Codes design ...... 14 3.3 Simulation chain, encoding block highlighted ...... 15 3.4 B-DMC channel ...... 17
3.5 Polarisation of W into N virtual channels, Un: input bit, Gn: see equa-
tion 3.5, Xn: bit after encoding, Yn: received bit ...... 17
3.6 Polarisation of W using G2 ...... 18 3.7 Simulation chain, rate matching highlighted ...... 19 3.8 Bit selection: repetition, puncturing, shortening ...... 20 3.9 Simulation chain, rate dematching highlighted ...... 21 3.10 Simulation chain, decoding block highlighted ...... 22 3.11 Successive Cancellation binary tree, L(n) is beliefs in node where n is number
of beliefs. uˆi represent a decoded bit and 0:s are frozen bits...... 24 3.12 Pre-order depth-first binary tree ...... 24 3.13 Simulation chain, included blocks highlighted ...... 27 4.1 Simulation chain, encode block highlighted ...... 30 4.2 Polar Encoding file scheme ...... 31 4.3 MATLAB code for encode_polar CRC calculation ...... 32 4.4 MATLAB code for encode_polar, mapping information bits to reliable vir- tual channels ...... 32 4.5 MATLAB code for getReliabilitySeq, collect the reliability sequence of size N ...... 33 4.6 MATLAB code for PolarEncode, encoding u_bits ...... 34
4.7 MATLAB code for getGn, generating Gi ...... 34
x 4.8 Simulation chain, rate matching block highlighted ...... 35 4.9 Rate matching file scheme ...... 35 4.10 MATLAB code for subBlock_interleaver ...... 36 4.11 MATLAB code for bit_selection ...... 37 4.12 MATLAB code for bit_interleaving ...... 38 4.13 Simulation chain, rate dematching block highlighted ...... 38 4.14 Rate dematching file scheme ...... 39 4.15 MATLAB code for bit_Deselection ...... 41 4.16 MATLAB code for subBlock_Deinterleaver ...... 42 4.17 Simulation chain, Polar decoding block highlighted ...... 42 4.18 Decoding file scheme for Successive Cancellation ...... 43 4.19 MATLAB code for decode_polar ...... 44 4.20 MATLAB code for SC_Decode ...... 45 4.21 MATLAB code from SC_Decode_Node, leaf operation ...... 47 4.22 MATLAB code from SC_Decode_Node, left/right/up part. Functions SplitLeft and SplitRight are code derived from equation 3.7 and 3.9 ...... 48 4.23 MATLAB code from variable initialisation in testEnvironment ...... 49 4.24 MATLAB code where the message is generated testEnvironment ...... 49 4.25 MATLAB code BLER calculation ...... 50 5.1 SC block size performance. Polar(N,K), subframes: 1000, CRC: crc24c .. 52 5.2 No rate matching vs repetition. Dotted lines are without rate matching and solid lines are with repetition. Polar(N, K) E , Subframes: 1000, CRC: crc24c...... 53 5.3 No rate matching vs puncturing. Dotted lines are without rate matching and solid lines are with puncturing. Polar(N, K) E , Subframes: 1000, CRC: crc24c...... 55
xi 5.4 No rate matching vs shortening. Dotted lines are without rate matching and solid lines are with shortening. Polar(N, K) E , Subframes: 1000, CRC: crc24c...... 56 5.5 Polar Codes versus Convolutional Codes, Subframes = 1000, transmission block size = 960, signal strength = [-5:0.5:5], message sizes(Left-to-right): 88, 144, 176, 208, 256, 328, 392, 472, 536, 616. Same color & marker = same message size ...... 57
xii 1 Introduction
Communication has always been important in all societies. It exists in many shapes and forms, such as verbal, written and transmitted by other means. In just a matter of decades the way we communicate over long distances has changed from sending paper letters, to real-time talk to each other with the help of telecommuni- cations. With real-time communications the phone usage has gone from needing to find a phone-booth to always having a phone in our pockets. As society has grown away from the patience we had waiting for those paper letters, to impatiently waiting for someone to return a missed call, the demand for reliable and fast data transmission has risen. With each generation of mobile network released, where 4G is currently used and 5G is being developed, the goal is to improve these data transmissions. With the use of channel coding the amount of errors which occur during transmission can be controlled and kept to a desirable amount. The algorithms used for channel coding are called error correction codes as their purpose is to restore messages transmitted over a channel and doing so even though the channel might be affected by noise. As 5G, also known as New Radio, is being developed, research and proposals were made on which algorithms should be used for channel coding. The 3GPP project, which unites telecommunications standard development organisations and companies, approved Polar Code as the channel coding algorithm for 5G control channels. Polar Codes has a recursive structure with low complexity and was proven to achieve channel capacity for long block lengths. Polar Codes was invented by Erdal Arikan and has been a hot topic since he published his paper in 2009 [1].
1 1.1 Thesis goal
This thesis was proposed by Tieto, an enterprise IT company with years of experience with development in the telecommunication sector [2]. Tieto has ongoing development within the newest telecommunication technologies and was in need of an in-depth view of the Polar Codes used in the New Radio (NR) technology. The goal of this thesis is to develop and implement Polar Codes. This includes an encoder which follows the 3GPP standard 38.212 and a decoder. Since there is no standard for a Polar decoder, research needed to be done to evaluate what algorithm to use in this thesis. One of the goals was to research different decoders and present these to Tieto before making a decision of which to implement. After the implementation of Polar Codes, Tieto wanted an evaluation of its performance using BLER/(Eb/N0)-graph. The evaluation of Polar Codes were to include performance for different block sizes, with and without rate matching. Finally Polar Codes was to be compared with Convolutional Codes, which is an error correction code used in Long Term Evolution (LTE). To do so Polar Codes had to be implemented into Tieto’s LTE-simulation environment.
2 1.2 Results
1.2.1 Expected results
Polar Codes is used in the control channel of the NR network, more commonly known as 5G. This suggests that the performance of Polar Codes should be better than the performance of Convolutional Codes used in LTE, more commonly known as 4G.
1.2.2 Actual results
The results and findings of this thesis correspond with initial thoughts. Polar Codesper- form better when larger block sizes are used with all different types of rate matching that are described in the adapted 3GPP standard. The implemented decoding algorithm for Po- lar Codes is Successive Cancellation. With this decoding algorithm Polar Codes performs better than Convolutional Codes in all simulations ran for this thesis.
1.3 Thesis outline
This thesis is focused on the comparison and evaluation of Polar Codes. The design and implementation of Polar Codes is described in detail and the results are evaluated. The thesis starts with chapter 2, explaining the background information required to understand the design and implementation. After the background information is covered, the design and implementation of Polar Codes are described in detail in respectively chapter 3 and 4. Finally, in chapter 5 and 6, the results and conclusions are covered, describing the evaluation and findings of this thesis.
3 2 Background
2.1 Introduction
To communicate, three parts need to be available, a sender, a receiver and a medium where the message can be sent over. These mediums are often subject to noise, and thus have the risk of message corruption upon transmission. The type of medium used in this thesis is a channel, namely radio channel. To compensate for the interference of noise, error correction codes are implemented where unreliable communication channels are used. The telecommunication industry relies heavily on the usage of error correction codes in the Long Term Evolution (LTE) and New Radio (NR) technologies, described in section 2.2.2 and 2.2.1 respectively. This thesis is focused on the performance of error correction codes. The codes that are to be evaluated are Convolutional Codes and Polar Codes. Polar Codes is the agreed upon 3GPP standard in the NR technology and is therefore interesting to evaluate in comparison with the older technology used in LTE, namely Convolutional Codes. Polar Codes can be implemented using different decoding algorithms and the impact of the algorithms on performance are also to be evaluated. This chapter covers the needed backgrounds information that is required to understand the subjects this thesis approaches.
4 2.2 Mobile broadband
Mobile broadband technology’s are used to enable wireless internet access to mobile devices. The technologies of interest for this thesis are LTE and NR. In the sections below LTE and NR are described in more detail.
2.2.1 Long Term Evolution
LTE is a mobile broadband technology and global standard, commonly known as 4G [3]. LTE has been used for about 10 years since its first commercial deployment in 2009. The technology was researched and developed by 3rd Generation Partnership Project (3GPP). 3GPP is a large organisation of member companies from all over the world working together to research and improve mobile communication technologies. LTE was designed to keep evolving to ensuring competitiveness over a ten-year-time-frame. The requirements for the evolution of LTE from 3G are, as quoted from [3]: • Reduced delays, in terms of both connection establishment and transmission latency; • Increased user data rates; • Increased cell-edge bit-rate, for uniformity of service provision; • Reduced cost per bit, implying improved spectral efficiency; • Greater flexibility of spectrum usage, in both new and pre-existing bands; • Simplified network architecture; • Seamless mobility, including between different radio-access technologies; • Reasonable power consumption for the mobile terminal.
2.2.2 New Radio
NR is a mobile broadband technology and global standard, commonly known as 5G [4]. NR is developed by 3GPP and is the successor to be of LTE. The NR technology has been under active development since 2015 and reached early deployments of 5G networks in 2018. NR has many similarities with LTE, and reuses many of its features.
5 The focus of NR can be divided into three categories;
• Enhanced mobile broadband (eMBB) - eMBB corresponds to achieving an enhanced user experience, by reaching higher data rates. • Massive Machine-Type Communication (mMTC) - mMTC corresponds to the technology supporting massive amounts of devices with low costs and energy consumption. • Ultra-Reliable and Low-Latency Communication (URLLC) - URLLC corre- sponds to the technology achieving high reliability and very low latencies.
2.3 Noise channels
To measure and quantify the performance of digital communication channels, such as wireless communication, one looks at the probability of bit error detection at a given disturbance, called noise. Many different noise models exist for a variety of different com- munication scenarios. A few examples of these types of noise models are Additive White Gaussian Noise (AWGN), Rayleigh fading and Random waypoint.
• AWGN is a model that can simulate the natural noise existing all around us, this noise can be caused by example thermal vibrations of atoms [5]. AWGN is the noise model used in the simulations for this thesis. • Rayleigh fading is used to simulate an urban environment where line of sight is nearly impossible between source and receiver [6]. • Random waypoint model is used to simulate mobile devices that change location, velocity and acceleration over time [7].
This thesis will be using AWGN as its noise channel, Tieto had an existing implementation which could be used and they wanted Polar Codes tested with it.
6 2.3.1 AWGN
AWGN is a basic noise model which is used to simulate the effect that natural random signals, known as background noise, will have on the wireless signal as seen in figure 2.1. Its name, AWGN, comes from the characteristics of the model as follows [5]. • Additive - The received transmission is equal to the transmitted signal plus noise. • White - The noise represents the idea of a uniform power across the whole frequency band, which means it does not appear different at other frequencies. • Gaussian - AWGN follows a Gaussian normal distribution, which means it can acquire both negative and positive values, with values closer to zero having a higher probability to appear. • Noise - Signal disturbance.
Figure 2.1: Effect of AWGN on a Signal of5 dB
7 2.4 Phase-shift keying
Digital modulation is a technique that is used for data transmission, namely, • Frequency-Shift keying (FSK). • Amplitude-shift keying (ASK). • Phase-shift keying (PSK). These are all modulation schemes which represents the data differently. This thesis is using PSK, which apart from telecommunication also is used for Bluetooth, RFID and Wireless LANs [8]. PSK is a technique where the carrier signal is modulated by varying the cosine and sine inputs at a particular time, where the sine carrier is split into 2n phases [9]. The distribution of phases are often represented using a constellation diagram which shows the in-phase as a dot on the complex plane, see figure 2.2.
Figure 2.2: Constellation diagram of 8-PSK (left) and BPSK (right)
By using more phase states, it is possible to have a higher data rate on the same bandwidth signal compared to using less phase states. This comes with the downside of adding more complexity to the modulation and a higher risk of misdetection. This thesis is using the simplest form of PSK, namely Binary Phase Shift Keying (BPSK), where sine carriers are represented by two phase states, 0-bit: 1 and 1-bit: -1, see figure 2.2.
8 2.5 Channel capacity
Channel capacity means in what rate information can be transmitted without compromis- ing the outcome on the receiving end. Transmitting bits at higher rates than the channel capacity will result in bits colliding on the receiving end and thus corrupting the output. Since a channel is always experiencing noise, one can not simple transmit a message of full channel capacity and expect complete recovery. This introduced the Shannon-Hartley Theorem which is a mathematical model where the channel capacity of a channel with the presence of noise can be calculated [10]. The theorem states that coding methods exists that can reach full channel capacity but can not be used to develop these codes.
2.6 Interleaving
Interleaving is a technique where a bit stream is interleaved by a known distribution pat- tern. This means that the bits are placed out of order, leading to more diversity within the bit stream. The advantage of using interleaving is that if a chunk of bits is lost in transmission, the error bits are spread out after deinterleaving making it easier for the error correction code to restore the original message.
2.7 Rate matching
Rate matching is a method where information blocks are manipulated so that the length of it matches the transmission rate [3]. How these information blocks can be manipulated depends on their size after encoding, which can either lead to shortening or extending of the block. How this is achieved depends on which standard is used. LTEs, rate matching for convolutionally coded transport channels is done in three steps, sub-block interleaving, bit collection and bit selection [11] to achieve desired sizes. NRs, rate matching for Polar Codes is also done in three steps, sub-block interleaving, bit selection and interleaving of coded bits [12]. In chapter 3, Design, rate matching for Polar Codes is described more extensively.
9 2.8 Error correction code
Error correction codes add redundancy to a message in such a way that the receiver can verify the integrity of the message and verify if the received message is correct and if not, even restore the message to a certain extent. Veronique Charlet et al. [13] explains error-correction codes in a simplified way, that a person who speaks, sending a signal to someone who is listening, by means of the air conveying the vibrations and forming the sound wave. Although, others might be talking nearby thus creating noise, making it harder for the receiver to hear the message. By yelling the message the speaker increases the probability that the message is heard, but this is far more exhausting. Instead of shouting, the speaker can add a number after each letter which correspond to the letter’s place in the alphabet. The extra data is redundant, but in the case of corruption, the numbers might help to clarify what the intended message really is.
2.8.1 Convolutional Codes
Convolutional Codes is a type of error correction code which operates on a bit stream. The bit stream is pushed through what can be seen as a sliding application. With every tick, each bit is moved further along the application creating a dependency between the bits. A more detailed description of Convolutional codes can be found in its design section 3.2. Convolutional Codes was introduced in 1955 by Peter Elias [14] when he showed that redundancy can be applied with the help of shift registers. Convolutional Codes are used in today’s LTE [11] control channel.
10 2.8.2 Polar Codes
Polar Codes, introduced by Arikan Erdal in 2009 [1], builds on the concept of channel polarisation. The code is in the first family to achieve maximum channel capacity onany symmetric binary-input discrete memory-less channel (B-DMC) and does this with low coding complexity O(NlogN), where the block length is represented by N.
Polar Codes are based on recursion where the original channel Wn is divided into virtual channels W1 and W2. Arikan proved that with enough division-recursion the cut off rate would be higher on the virtual channel than the original channel and thatthe virtual channels tend to have either high reliability or low reliability. This means that the channels are either completely noisy or noiseless, where the noiseless channels should be chosen to transmit data on. Polar Codes was agreed upon to be used in the upcoming 5G - NR technology [12], replacing the now used Convolutional Codes in LTE.
2.9 Eb/N0
Energy per bit to noise power spectral density ratio (Eb/N0) is a measurement used to evaluate the strength of a channel, where higher values correlates to a strong signal and lower values correlates to a weak signal. Eb/N0 is presented in decibel (dB).
2.10 Block error rate
Block error rate (BLER), is a ratio between number of blocks containing errors to the total number of transmitted blocks. BLER is calculated after the decoding and evaluates the cyclic redundancy check (CRC), which is a type of checksum, for each transported block [15]. The CRC is appended onto each transmitted block and the block will only be marked as successfully transmitted if the CRC-attachment matches the CRC calculated by the receiver.
11 2.11 MATLAB
MATLAB is a development environment and programming language [16]. The program- ming language relies heavily on matrices, making it the perfect environment to handle large data collections. MATLAB is used to simulate the physical communication layer with code provided by Tieto and calculates the simulation results to a BLER-Eb/N0 graph.
2.12 Summary
In this chapter, the background of this thesis was introduced and the needed terms to understand the goal of this thesis have been introduced and explained. This chapter has introduced mobile broadband technologies LTE and NR, where some crucial parts of the technologies have been described in more detail. The main focus is on the description of the different error correction codes and its dependencies.
12 3 Project Design
3.1 Introduction
In this chapter the overall design of the project is introduced and described. The highlighted blocks in the transmission chain, seen in figure 3.1, represent the design and implementation scope of this thesis. The same figure can be used to describe the transmission chain for Convolutional Codes, with the exception of which encode and decode algorithm is used. Blocks highlighted in figure 3.1 are described in this chapter where the main focus is on Polar Codes with the chosen decoding algorithm, Successive Cancellation.
Figure 3.1: Simulation chain
13 3.2 Convolutional Codes
The design structure of Convolutional Codes is as follows; A bit stream (denoted C), containing x number of bits, is pushed through m number of memory registers (denoted D), each holding one input bit. The bits are then pushed through a XOR gate, as shown in figure 3.2, which gives an output bit stream.
Figure 3.2: Convolutional Codes design
Convolutional Codes are denoted as (n, k, m) [17, ch.6], where n is the number of input bits, k is the number of output bits and m is the number of memory registers. The rate is denoted n/k (rate 1/3 in figure 3.2), meaning that for every n input bit(s) there are k output bit(s). After each time frame all registers perform a bit shift to the right, meaning that new bits come in and the bit currently in last register is dropped. The scope of this thesis does not include the implementation of Convolutional Codes, but rather its performance compared to Polar Codes. This thesis uses an already existing implementation of Convolutional Codes, according to 3GPP 36.212 [11], provided and implemented by Tieto. Since the implementation is Tietos proprietary software, this thesis will not include any source code of Convolutional Codes.
14 3.3 Polar encoder
Figure 3.3: Simulation chain, encoding block highlighted
Polar encoder is the first step in Polar Codes. The Polar encoder is used by the sender, see figure 3.3, to modulate the message such that the receiver will know how to decode and verify the message. In the encoder the information bits are mapped according to a reliability sequence found in 3GPP 38.212 specification, see section 3.3.1. The reliability sequence is built upon the channel polarisation which the channel undergoes in the encoder, explained in section 3.3.2.
3.3.1 3GPP 38.212
The 3GPP 38.212 [12] standard holds many specifications regarding the usage and imple- mentation of channel coding. Not all of the specifications listed in 38.212 are implemented in this thesis. 3GPP 38.212 describes how the Polar Codes are implemented in NR control channels. This thesis focuses on evaluating the performance between different channel codes and algorithms when transmitting over an AWGN channel. Since the evaluations are performed on a LTE-simulation the interleaver will not be used on any of the channel codes. This is because the interleaver is done differently in LTE and NR. Thus making it harder to
15 evaluate the code performances. Along with the sent data, the 3GPP 38.212 also includes specific ways of using cyclic redundancy checks (CRC) that are used in different implementations of Polar Codes in the physical channels. This thesis will focus on the implementation of Polar Codes in the Control Channel, therefore a CRC of size 24 [12, ch 7.3.2], namely crc24c is used as described in [12, ch 5.1]. 3GPP 38.212 includes a Polar reliability sequence that is used to determine the ”frozen bits” and which channel the information bits should be sent on, further explained in the fol- lowing section. The Polar reliability sequence is established by sorting the virtual channels by their channel capacity from worst to best.
3.3.2 Encoding and channel polarisation
The purpose of an encoder is to translate information from a sender to a code-word which is then transmitted to the receiver. As the transmission can be affected by noise, which disrupts the signal, the encoder also needs to add security to the message in such a way that the decoder still can restore the message even though that some bits might be flipped. To do so Polar Codes are assuming that a Binary Discrete Memoryless Channel (B- DMC) [18] is used [1].
P r{X = x, Y = y} (3.1)
As seen in equation 3.1 where x and y are discrete alphabets, in this case x = {0, 1} and y = {0, 1}, B-DMC represents bits that can ether be 1 or 0. X and Y respectively are input and output values, where X is a value in x and Y is a random value in y. This leads to equation 3.2.
16 W : P r{X = x, Y = y} = P r{X = x}p(Y |X) (3.2)
For the rest of the thesis equation 3.2 is denoted W , for all (X,Y ) ∈ x × y. The goal of Polar encoding is to take W , see figure 3.4, and make N copies that are combined and split into different virtual channels, see figure 3.5. The virtual channels are either ”noiseless” or completely ”noisy” channels [1]. The noise which is referred to is the information which is added from other channels, see figure 3.6 where U1 is considered more noisy than U2. The more channels that are polarised the larger the gap between the noiseless and noisy channels becomes. The combination of virtual channels is done by using a Kronecker
Figure 3.4: B-DMC channel
Figure 3.5: Polarisation of W into N virtual channels, Un: input bit, Gn: see equation 3.5, Xn: bit after encoding, Yn: received bit
product of the matrix G2, see expression 3.3, where the rows of the matrix represents the virtual channels a bit should be transmitted on and the columns represent whether or not the bit should be XOR:ed when combining the virtual channels. An illustration of G4 and
GN respectively can be seen in equations 3.4 and 3.5.
17 1 0 G2 = (3.3) 1 1
1 0 0 0 1 1 0 0 G4 = (3.4) 1 0 1 0 1 1 1 1
[ ] ⊗n GN = G2 (3.5)
The process of combining two W copies is illustrated in figure 3.6. A Polar encoded
Figure 3.6: Polarisation of W using G2 transmission is denoted as (N,K), where K = length of the message and N > K, N = 2n, n = 2, 3, ..., 10 which forms a vector u of length N bits. The remaining N −K bits are called frozen bits with a set value of 0. The u vector is then mapped to the channels according to a reliability sequence. The frozen bits are placed on the least reliable channels, called frozen positions and the information bits are placed in the most reliable channels, called information positions. After the channels are combined, the output from the encoder is a code-word denoted as vector d, where d = uGn mod 2.
18 3.4 Rate matching
Figure 3.7: Simulation chain, rate matching highlighted
Rate matching is about matching the number of bits to the desired transmission rate, see section 2.7. Rate matching for Polar Codes is performed after encoding and before the bits are sent over the channel as seen in figure 3.7. For Polar Codes there are three parts to rate matching, sub-block interleaving, bit selection and interleaving. For this thesis sub-block interleaving and bit selection was implemented according to the 3GPP 38.212 standard [12]. These parts are described in more detail in the following sections. Bit interleaving is outside of the scope of this thesis and therefore not implemented.
3.4.1 Sub-block interleaving
Sub-block interleaving distributes bits, as described in section 2.6, according to a specific interleaver pattern. The bit distribution uses 32 bit sub-blocks that are redistributed following the sub-block interleaver pattern in the 3GPP 38.212 standard [12, table:5.4.1.1- 1]. The distribution also takes into account which bits are ”punctured” or ”shortened” in the bit selections part of rate matching.
19 3.4.2 Bit selection
Bit selection uses three main techniques to achieve the desired number of transmission bits, these are: repetition, puncturing and shortening as described in figure 3.8.
Figure 3.8: Bit selection: repetition, puncturing, shortening
Repetition is used when the desired transmission bits are greater than the encoded bits, and as the name suggests, repeats the encoded bits. Using repetition the bits are sent multiple times within the transmission. This achieves a bit redundancy that makes it less likely that a bit is wrongly decoded. Puncturing and shortening are techniques used only when the desired transmission bits are less than the encoded bits. Puncturing removes bits from the start of the 32 bit sub- blocks and is used when the ratio between information bits and the desired transmission bits is less or equal than 7/16 according to the 3GPP 38.212 standard [12]. Shortening removes bits at the end of the 32 bit sub-blocks and is used when puncturing is not used meaning that the ratio between information bits and desired transmission bits is greater than 7/16 according to the 3GPP 38.212 standard [12]. Both of these options are needed as Polar Codes is dependent on frozen bits. As explained, puncturing removes the bits from the start of the block, which often are Frozen Bits. But if the ratio between information bits and transmission bits is greater than 7/16 shortening has to be used, because otherwise there would be too few frozen bits.
20 3.5 Rate dematching
Figure 3.9: Simulation chain, rate dematching highlighted
Rate dematching is performed on the received bits to restore the encoded bit structure so that the Polar decode algorithm can decode the message as seen in figure 3.9. Rate dematching consists of three parts, sub-block deinterleaving, bit deselection and deinter- leaving. Just like interleaving in rate matching, deinterleaving is outside of the scope of this thesis. Sub-block deinterleaving and Bit Deselection are described in the following sections.
3.5.1 Bit deselection
Bit deselection needs to reconstruct the encoded bits that were manipulated using the three techniques in bit selection, see section 3.4.2. Received bits that were manipulated with repetition in bit selection are added up for every recurrence of a bit, creating a stronger belief for that bit. Received bits that were manipulated with puncturing in bit selection will have zeros set at the start of the encoded bits, and for shortening, bits will have zeros set at the end of the encoded bits. The zeros are added to replace the bits that were removed during bit selection.
21 3.5.2 Sub-block deinterleaving
Sub-block deinterleaving is done by redistributing the bits back to how they were dis- tributed before sub-block interleaving, see section 3.4.1. Redistributing is performed ac- cording to the reversed Sub-Block interleaver pattern in the 3GPP 38.212 standard [12, table:5.4.1.1-1].
3.6 Polar decode
The Polar decoder receives a Polar encoded message that was transmitted over an AWGN channel as seen in figure 3.10. Because of the noise on the AWGN channel, the received message values includes signal offsets compared to the message that was sent. Polar Codes is designed to be able to correct these offsets and reconstruct the correct message from the received data.
Figure 3.10: Simulation chain, decoding block highlighted
There are a variety of algorithms for decoding Polar encoded messages. Arikan pro- posed the Successive Cancellation (SC) technique in 2009 [1] as one of the first decoding algorithms for Polar Codes. As part of this thesis different algorithms were presented to Tieto with a top level description of their design and decoding approach. The researched and presented algorithms were:
22 • Successive Cancellation [1]. • Successive Cancellation List [19]. • Belief Propagation [20]. • Belief Propagation List [21]. • Low-Complexity Software Stack Decoding (Based on Successive Cancellation) [22]. • Successive Cancellation Priority Decoding [23]. Most algorithms that could be found were based upon SC with added complexity for better performance. Therefore SC were chosen as the decoder to be implemented for this thesis. An attempt was made to also implement Successive Cancellation List, since this has a significant code gain compared to SC[19]. Unfortunately time did not allow completion of SCL decode algorithm.
3.6.1 Belief
Beliefs, denoted as L, are the transmitted values that the decoder receives. These are represented as negative values for bit value 1, and positive values for bit value 0. The strength of the belief are the absolute value of L, where larger values represent stronger beliefs. Example, |L| = 0.15 can be considered as a weak belief, while |L| = 30 can be considered as strong belief.
3.6.2 Frozen bits
Decoding the received beliefs can be done with different algorithms, but the frozen bits will always be handled the same way. The Polar encoder sets frozen bits that represent the virtual channels with the most noise, sorted from worst to best in the reliability sequence found in 3GPP standard [12]. Information bits are never sent over the frozen bit channels. When decoding the received beliefs, the frozen bits should always be set to 0 regardless of what value the belief has.
23 3.7 Successive Cancellation
Because of the way the Polar Codes are structured, the received values, r, from the channel can be represented as a binary tree. The sequence in which the received beliefs, L, are decoded is similar to a pre-order depth-first search tree as seen in figure 3.11.
Figure 3.11: Successive Cancellation binary tree, L(n) is beliefs in node where n is number of beliefs. uˆi represent a decoded bit and 0:s are frozen bits.
Figure 3.12: Pre-order depth-first binary tree
24 The binary tree structure is made of nodes and leaf-nodes, where a node always has two children. A leaf-node is a node without children [24]. The operations in nodes can be split into four states: Leaf, Left, Right and Up, where the leafs represent the decoded message bits. The Leaf state will only be used if the node is a leaf and the Left and Right states will only be used in non-leaf nodes. As seen in figure 3.12, in a pre-order depth-first search tree, the order of these states will always be: 1. Check if the node is a leaf, if so, perform leaf state operations. 2. Check if the node is not a leaf, if so, perform left operations followed by right oper- ations. 3. The up state operations are always performed as the last operations in any node.
3.7.1 Leaf state
The leaf state for a node is about calculating the corresponding decoded bit for the leaf and setting uˆi, representing the estimated bit value. If the leaf represents a frozen bit position, the value of the belief Li that was passed down to the leaf is ignored and uˆi is set to zero.
If the leaf represents a non-frozen bit position, the value of the belief Li is used to determine what value to set to uˆi as seen in equations 3.6.
Li ≥ 0 :u ˆi = 0 Li < 0 :u ˆi = 1 (3.6)
25 3.7.2 Left state
The left state for a node is about sending the correct beliefs Li to the node’s left child, see equations 3.7. The beliefs are split into two parts, a and b.
a = Ln(1, 2, 3, ..., n/2) b = Ln(n/2 + 1, n/2 + 2, n/2 + 3, ..., n/2 + n) (3.7)
The polarisation that is performed on the virtual channels during encoding, as seen in figure 3.6, is the bases that leads to equation 3.8.
Ln/2 = sgn(a) × sgn(b) × min(|a|, |b|) (3.8)
For each value in a and b the signs are multiplied and result is then multiplied with the smallest value of the absolute values of a and b. This is done because the value closest to zero is a value from the most unreliable virtual channel.
3.7.3 Right state
The right state for a node is about sending the correct beliefs Ln to the node’s right child. This state is performed after the left state is done because the result of the left child is used to determined what data is sent to the right child.
The a and b values from left state, as seen in equation 3.7, are also used in the right state. The right state is depending on the value uˆi from the left child, where uˆi represent the bit calculated for the polarised virtual channels as seen in equations 3.9. As several bits might have been set by the left child, i is an index for each bit set by the left child.
uˆi = 0 : Ln/2 = b + a uˆi = 1 : Ln/2 = b − a (3.9)
26 3.7.4 Up state
The up state for a node is about sending the gathered and calculated data to the parent node. This state is used in both nodes and leaf-nodes and is the final state that contains the decoded bits in the root node. The up state is done as the last action in any node.
For leaf-nodes the calculated uˆi is used and other nodes are reconstructing the polarised virtual channel structure using the calculated uˆ values as seen in equation 3.10. Lastly the uˆi value is sent up to the parent node. An example can be seen in 3.11.
uˆi = [ˆuleft ⊕ uˆright, uˆright] (3.10)
uˆleft = [1] uˆright = [1] uˆi = [01] (3.11)
3.8 Simulation
Figure 3.13: Simulation chain, included blocks highlighted
The simulation environment is where channel codes are tested and evaluated. The simulation environment uses a range of parameters that makes it possible to test and evaluate different performance aspects. As seen in figure 3.13 the scope of this thesis is
27 limited to the blocks highlighted. Each block represent a module with a specific purpose. This thesis uses two different simulation environments. One that is used to simulate the performance of Polar Codes using different Polar Codes parameters and one environment to compare Polar codes with Convolutional Codes. The environment used to simulate Polar Codes performance is described in further detail in the implementation section 4.7, whereas the environment used in performance comparison to Convolutional Codes is provided and owned by Tieto and therefore will not be described in detail. When comparing Polar Codes to Convolutional Codes, the blocks are in the same sequence, but Polar encoding/decoding-modules will be replaced with Convolutional encoding/decoding-modules.
3.8.1 Parameters
Parameters of interest for this thesis are PolarBlockSize, InformationBits, Transmission- Blocksize, Eb/N0(db), Noise and SubFrames. • PolarBlockSize - Different block sizes are tested and evaluated against each other in the same conditions. This allows analysis on performance variations depending on the size of the blocks being encoded and decoded. Possible block sizes for Polar Codes are 2n, where 5 ≤ n ≤ 10 as specified in 3GPP 38.212 [12]. • InformationBits - The amount of message bits and CRC bits combined. This pa- rameter should mostly be half the PolarBlockSize except for simulations evaluating rate matching using puncturing in bit selection. • TransmissionBlocksize - Different transmission block sizes are evaluated using rate matching to achieve the desired sizes.
• Eb/N0 (dB) - A range of values representing the signal strength in the channel as
described in section 2.9. Performance results with different Eb/N0 (dB) are interest- ing to measure and compare to see the performance differences, in decibel between simulations.
28 • Noise - AWGN is the type of noise used for all the simulations in this thesis, as described in section 2.3.1. • SubFrames - The subframes are used to run a simulation multiple times using the same settings to be able to get statistical data from the results. In LTE and NR one SubFrame corresponds to one millisecond time period for a transport block transmission. More subframes will yield more accurate results for the simulation.
3.8.2 Performance comparisons
Performance comparisons are represented with a BLER vs Eb/N0 graph. BLER is on the y-axis and presented with a logarithmic-scale and corresponds to a percentage of blocks that are seen as erroneous, see section 2.10. Eb/N0 is on the x-axis and corresponds to the signal strength in dB, see section 2.9.
3.9 Summary
In this chapter the overall project design for this thesis was described. The Convolution Codes used in LTE have briefly been explained but the focus is more on the Polar Codes used in NR. The 3GPP 38.212 standard for NR was introduced and described along with the Polar encoder. The design of the chosen decoding algorithm, Successive Cancellation, was introduced along with its decoding concept. The simulation process was described and the different possible parameters were explained.
29 4 Project Implementation
4.1 Introduction
In this chapter the implementations of Polar Codes, rate matching and the simulation environment developed for the testing of Polar Codes are described. This chapter has five main sections: Polar encoder, rate mathcing, rate dematching, Polar decoder and simulation. The Polar decoding algorithm in this thesis is a recursive implementation of Successive Cancellation. The following sections contains a thorough description where each implementation is explained in detail with the help of code snippets.
4.2 Convolutional Codes
The Convolutional Codes that is used in this thesis is being developed and maintained by Tieto and will therefore not be described in detail. The Convolutional encoder was implemented following the 3GPP 36.212 standard [11]. The scope of this thesis does not include the implementation of Convolutional Codes.
4.3 Polar encoder
Figure 4.1: Simulation chain, encode block highlighted
30 The Polar encoder is implemented according to the 3GPP 38.212 standard except for the interleaver [12]. The interleaver, see figure 3.3, is not relevant to this thesis because the main focus is on the performance of the algorithms. The Polar encoder is written in MATLAB and implemented in a LTE simulation environment provided by Tieto. This thesis implementation of the Polar encoder is a combination of four files as seen in figure 4.2, this design is used to keep the same design pattern as used in the simulation environment. Because of the way the Polar encoder is implemented in the simulation envi- ronment, the core of the encoder is the encode_polar function. The encode_polar function gets the input bits as a parameter, encodes the bits by using the functions mentioned below, and then returns the encoded bits, e_bits.
Figure 4.2: Polar Encoding file scheme
4.3.1 encode_polar.m
The encode_polar function receives four parameters: • trBlock - Transport block. • N - Transport block size. • crcType - Variable containing name of CRC. • rnti - Variable that is used to calculate a unique CRC. The crcType and rnti values are used to calculate the CRC that is appended to trBlock and placed in vector b_bits as seen in figure 4.3. When b_bits is constructed, the length K of b_bits is used to calculate N, where
31 if strcmpi(crcType, 'crc16') %[D16 + D12 + D5 + 1] gCrc =[10001000000100001]; crcXor = dec2bin(rnti, 16) - '0'; elseif strcmpi(crcType, 'crc24c') %[D24+ D23+ D21+ D20+ D17+ D15+ D13+ D12+ D8+ D4+ D2+ D+ 1] gCrc=[1101100101011000100010111]; crcXor = dec2bin(rnti, 24) - '0'; elseif strcmpi(crcType, 'crc11') %[D11 + D10 + D9 + D5 + 1] gCrc = [1 1100010000 1]; crcXor = dec2bin(rnti, 11) - '0'; else error('Unknown crcType'); end
b_bits = crcCalc(trBlock(:), gCrc, crcXor);
Figure 4.3: MATLAB code for encode_polar CRC calculation
N > K, N = 2n, n = 2, 3, ..., 10 and is the number of virtual channels that are used during encoding and transmission. N is used to get the reliability sequence from getReliabilitySeq and the sequence is placed in QN . QN contains the positions of the most reliable channels in ascending order.
Vector u_bits is of size N and initialised with all zeros. The information bits, b_bits, are mapped to u_bits using the K most reliable channels of the reliability sequence in QN as seen in figure 4.4. This way the frozen bits are the unused positions which has value 0 from the initialisation.
%Collects the reliability sequence of size N Qn = getReliabilitySeq(N); %Generates the u_bits and assign the information bits according to Qn. u_bits = zeros(1, N); u_bits(Qn(N - K+1 :1 :end )) = b_bits;
Figure 4.4: MATLAB code for encode_polar, mapping information bits to reliable virtual channels
32 Vector u_bits is then sent to PolarEncode to be encoded and returned into vector e_bits. e_bits is then returned to the simulation environment that transmits e_bits to the receiver simulation code.
4.3.2 getReliabilitySeq.m The reliability sequence is defined by the 3GPP 38.212 standard and implemented asa large vector with the values found in 3GPP 38.212 [12, table:5.3.1.2-1]. The vector Q contains the full reliability sequence for N = 1024. getReliabilitySeq will receive a value
N when called and collect the channel positions where Qi ≤ N, the positions are placed in vector Qn and returned as seen in figure 4.5.
function Qn = getReliabilitySeq(N) % Reliability sequence from 3GPP 38.212 Table 5.3.1.2 -1 Q = [0 1 2 4 8 16 32 3 5 64 9 6 17 10 18 128 12 33 65 ... (1024 values)] % Returns reliability sequence for positions ≤ N Qn = Q(Q ≤ N);
Figure 4.5: MATLAB code for getReliabilitySeq, collect the reliability sequence of size N
4.3.3 PolarEncode.m In this function the encoding of the bits is performed. The function receives a input vector u_bits which contains the information bits along with the frozen bits. After receiving the n : th Kronecker product of G2 from getGn a matrix multiplication is performed as u_bits × Gn and placed into e_bits as seen in figure 4.6. Equation 4.1 illustrates a matrix multiplication for a 4-bit encoding. The output is then taken as mod2 since there can only be bit values. 1 0 0 0 [ ] [ ] 1 1 0 0 u u u u = u + u + u + u u + u u + u u (4.1) 1 2 3 4 1 2 3 4 2 4 3 4 4 1 0 1 0 1 1 1 1
33 function e_bits = PolarEncode(u_bits) N = length(u_bits); % Generate the Kronecker product of u_bits. Gn = getGn(N); % Generates e_bits according to GF(2) e_bits = mod(u_bits*Gn ,2);
Figure 4.6: MATLAB code for PolarEncode, encoding u_bits
4.3.4 getGn.m getGn is used to generate the Kronecker product of the matrix G2 for size N as seen in figure 4.7. This is done by first generating G2 as seen in equation 3.3 after which a
Kronecker product of two G2 is calculated creating G4 as seen in equation 3.4, and stored in Gi. Gi is then calculated repetitively using Kronecker product of the previous Gi and
G2 until Gi has the number of rows equal to N as seen in equation 3.5.
% Generates n:th Kronecker Matrix with G2. function Gi = getGn(N) % Generate basic G2 G2=[1 0 ; 1 1]; Gi = G2; n = log2(N); % Grow Gi to size N for i=1:n-1 Gi = kron(Gi , G2); end
Figure 4.7: MATLAB code for getGn, generating Gi
34 4.4 Rate matching
Figure 4.8: Simulation chain, rate matching block highlighted
Rate matching is performed on polar encoded bits before the bits are sent over the channel, as seen in figure 4.8. Rate matching was implemented following the 3GPP 38.212 standard [12].
4.4.1 rateMatch_polar.m
This is the main function for rate matching, it holds the three different steps that rate matching for Polar Codes does, following the 3GPP 38.212 standard [12]. rateMatch_polar takes five parameters and consists of three steps as seen in figure 4.9.
Figure 4.9: Rate matching file scheme
35 The parameters used when calling rateMatch_polar are as follows: • d_bits - Encoded bits to perform rate matching on. • N - Block size for Polar Codes. • K - Number of information bits. • E - Desired block size. • I_bil - Flag to enable bit interleaving. First the rate matching code calls subBlock_interleaver, second the bit_selection and third bit_interleaving. After these functions have manipulated the bits, rate matching is com- plete and f_bits is returned.
4.4.2 subBlock_interleaver.m
The subBlock_interleaver takes two parameters: • d_bits - bits to perform sub-block interleaving on. • N - Block size for Polar Codes. Sub-block interleaving makes use of a sub-block interleaver pattern described in sec- tion 3.4.1. Using the pattern the bits are redistributed into sub-blocks of size 32 as seen in figure 4.10.
function y_bits = subBlock_interleaver(d_bits, N) P = [0 1 2 4 3 5 6 7 8 16 9 17 10 18 11 19 12 20 13 21 14 22 15 23 ... 24 25 26 28 27 29 30 31]; J = []; for n = 0:1:N-1 i = floor((32*n)/N); J(n+1) = P(i+1)*(N/32) + mod(n, N/32); y_bits(n+1) = d_bits(J(n+1)+1); end end
Figure 4.10: MATLAB code for subBlock_interleaver
36 4.4.3 bit_selection.m
Bit selection takes four parameters and consists of three parts as described in section 3.4.2. The parameters are: • y_bits - Bits to perform bit selection on. • N - Block size for Polar Codes. • K - Number of information bits. • E - Desired block size. N, K and E are used to determine what kind of bit selection to perform as seen in figure 4.11. Repetition is performed when E ≥ N, puncturing is performed when K/E ≤ 7/16 and shortening is performed when K/E > 7/16.
function e_bits = bit_selection(y_bits, N, K, E) if (E ≥ N) % Repetition e_bits = y_bits(mod(0:1:E-1, N)+1); else if((K/E) ≤ (7/16)) %Puncturing e_bits = y_bits(N-E+1:1:N); else %Shortening e_bits = y_bits(1:E); end end end
Figure 4.11: MATLAB code for bit_selection
4.4.4 bit_interleaving.m
Bit interleaving takes three parameters: • e_bits - Bits to perform bit interleaving on. • E - Desired block size. • I_bil - Flag to enable bit interleaving.
37 Bit interleaving is outside of the scope of this thesis, and therefore the I_bil flag will always be set to zero and return f_bits equal to e_bits as seen in figure 4.12
function f_bits = bit_interleaving(e_bits, E, I_bil) if(I_bil == 1) % Not implemented error('Polar interleaving not implemented'); else f_bits = e_bits; end end
Figure 4.12: MATLAB code for bit_interleaving
4.5 Rate dematching
The rate dematching happens before Polar decoding, see figure 4.13, and has the function of reversing the changes made by rate matching. To do so each step described in the standard and implemented in rate matching had to be analysed so that a reverse function of each part could be developed. In this section the files created for the rate dematching are presented and described with the help of code snippets.
Figure 4.13: Simulation chain, rate dematching block highlighted
38 4.5.1 DerateMatch_polar.m
As the receiver side of the simulation has demodulated the received bits these are sent to the rate dematcher with the function call DerateMatch_polar. The parameters given to this function are as follows:
• llr - This vector contains the Log Likely-hood ratios (LLR). In other terms the beliefs for each transmitted bit. • N - This is an integer value which refers to the block size of information bits plus frozen bits. This is needed so that the rate dematching restores the bits to the correct block size. • K - An integer value which refers to the number of information bits that were sent. • E - An integer value which refers to the block size of the transmission. • I_bil - A flag indicating if bit interleaving should be performed. For this thesis I_bil will always have a value of 0.
DerateMatch_polar calls, in given order, bit_Deinterleaving, bit_Deselection and sub- Block_Deinterleaver with the correct parameters as seen in figure 4.14. The order of the calls are given in the reverse order compared to rate matching.
DerateMatch_polar then returns the rate dematched bits back to simulations chain.
Figure 4.14: Rate dematching file scheme
39 4.5.2 bit_Deinterleaving.m bit_Deinterleaving deinterleaves coded bits. In this function the I_bil flag is used. Al- though, since it is always set to zero, because of the scope for this thesis, the only function of bit_Deinterleaving is to place the llr values into another vector called deInterleav_llr and then return this vector.
4.5.3 bit_Deselection.m bit_Deselections function is to restore the length of the transmitted bits so that it matches the length of encoded bits. The length of the encoded bits has either been extended or shortened depending on if N is larger or smaller than E. These values are sent in as parameters and are as follows: • deInterleav_llr - This vector contains the LLR/beliefs for the transmitted bits. • N - This is an integer value which refers to the block size of information bits + frozen bits that the encoder had. This is need so that the rate dematcher restores the bits to the correct block size. • K - An integer value which refers to the number of information bits that was sent. • E - An integer value which refers to the block size of the transmission. First decision taken by bit_Deselection is depending on the ratio between E and N, see figure 4.15. If E ≥ N then this means that puncturing, see section 3.4.2, was made on the encoded bits before transmission. As seen in figure 4.15 the first N bits from deInterleav_llr are placed into deSelected_llr. The last E−N bits are then looped through and their beliefs are added on to the corresponding index in deSelected_llr. This makes the beliefs for these bits stronger. If E < N it means that bits were removed before transmission. One of two operations was performed, either puncturing or shortening. For both cases zeros are added for the removed bits, but the placement of them depends on which operation has been made, see figure 4.15. A belief of zero correspond to a neutral belief, meaning that it is equally likely that the removed bit were a 0 or 1.
40 function deSelected_llr = bit_Deselection(deInterleav_llr, N, K, E) if (E ≥ N) % Repetition deSelected_llr = deInterleav_llr(1:N); for k = N:1:E-1 index = mod(k, N)+1; deSelected_llr(index) = deSelected_llr(index) + ... deInterleav_llr(k+1); end else if((K/E) ≤ (7/16)) %Puncturing deSelected_llr = [zeros(1, N-E) deInterleav_llr]; else %Shortening deSelected_llr = [deInterleav_llr zeros(1, N-E)]; end end end
Figure 4.15: MATLAB code for bit_Deselection
4.5.4 subBlock_Deinterleaver.m subBlock_Deinterleavers function is to restore the order which was interleaved by sub-block interleaver on the transmitter side. The parameters used when calling subBlock_Deinterleaver are as follows: • deSelected_llr - LLR/beliefs values, that are to be rearranged to restore their order before decoding. • N - Block size used for the Polar encoding. To redistribute the bits back to the order of the encoded bits, subBlock_Deinterleaver uses the pattern described in section 3.5.2. The implementation of sub-block deinterleaver can be seen in figure 4.16.
41 function r_deMatched = subBlock_Deinterleaver(deSelected_llr, N) P = [0 1 2 4 3 5 6 7 8 16 9 17 10 18 11 19 12 20 13 21 14 22 15 23 ... 24 25 26 28 27 29 30 31]; J = []; for n = 0:1:N-1 i = floor((32*n)/N); J(n+1) = P(i+1)*(N/32) + mod(n, N/32); r_deMatched(J(n+1)+1) = deSelected_llr(n+1); end end
Figure 4.16: MATLAB code for subBlock_Deinterleaver
4.6 Polar decoder: Successive Cancellation
Figure 4.17: Simulation chain, Polar decoding block highlighted
This section includes how the Successive Cancellation (SC) decoding algorithm was implemented for this thesis. Polar decoding is the last step done before message verification and BLER-calculations, see figure 4.17. The decoding algorithm was implemented using recursion. As Polar Codes can be represented using a perfect binary tree, it makes recursion a valid option with the use of pre-order depth-first traversal. The implementation is split into three files decode_polar, SC_Decode and SC_Decode_Node, see figure 4.18. decode_polar is the function that is called as the main function for the
42 decoding algorithms. The function prepares variables which then are sent to SC_Decode which starts the SC decoder. SC_Decode calls the SC_Decode_Node which starts the traversal and recursion.
Figure 4.18: Decoding file scheme for Successive Cancellation
4.6.1 decode_polar.m
The implementation of the decoder starts in the decode_polar-file. This function is used before the decoding algorithms. This function acts as a gateway from the current imple- mentation of LTE-simulation such that the right in-/output values are used. The in-parameters are: • e_bits - Vector containing encoded received bits represented by their belief values. • N - Variable containing the size of received transmission. • K - Variable which contain the number of information bits transmitted. • crcType - String variable that contains a reference to which CRC-attachment size have been used when encoding the information bits. • crcXor - Vector containing the binary values of rnti represented by n number of bits, where n is the CRC length. Outputs values are: • trBlock - Vector containing the decoded bits. • crcFlag - Variable that contains the number of CRC errors found.
43 function [trBlock, crcFlag] = decode_polar(e_bits, N, K, crcType, crcXor) if strcmpi(crcType, 'crc16') %[D16 + D12 + D5 + 1] gCrc =[10001000000100001]; crcSize = 16; elseif strcmpi(crcType, 'crc24c') %[D24+ D23+ D21+ D20+ D17+ D15+ D13+ D12+ D8+ D4+ D2+ D+ 1] gCrc=[1101100101011000100010111]; crcSize = 24; elseif strcmpi(crcType, 'crc11') %[D11 + D10 + D9 + D5 + 1] gCrc = [1 1100010000 1]; crcSize = 11; else error('Unknown crcType'); end
c_bits = SC_Decode(e_bits, N, K);
%Puts information bits - crc bits into a_bits a_bits = c_bits(1:K-crcSize); crcBits = c_bits(K-crcSize+1 :end );
% Check CRC crcCheck = crcCalc(a_bits, gCrc, crcXor); crcFlag = sum(crcBits(:) ≠ crcCheck); trBlock = a_bits;
Figure 4.19: MATLAB code for decode_polar
The function starts with an if-statement which verifies which CRC-attachment has been used for the encoding of the information bits. This is needed towards the end of the function when the decoded bits have to be verified. The function then calls SC_Decode with the parameters e_bits, N and K which returns the actual decoded bits without frozen bits, and these are put in variable c_bits. c_bits now contains the decoded information bits, (message+CRC). The function will separate these into a vector containing the message bits and another containing the CRC bits. Message bits and CRC bits respectively are placed in a_bits and crcBits. A new CRC attachment is then calculated for a_bits using gCrc and crcXor and is placed into crcCheck, the values are then compared with the decoded CRC and the number of mismatches are placed into crcF lag.
44 4.6.2 SC_Decode.m
This function acts as a starting point for the recursive function call and restructures the returned results according to the reliability sequence. In-parameters are: • d_bits - Vector containing encoded received bits represented by their belief values. • N - Variable containing the size of received transmission. • K - Variable which contain the number of information bits transmitted. Output value is: • c_bits - Vector containing the information bits (Frozen bits are removed). This function starts of by doing a call to the recursive function SC_Decode_Node with all its input values. It also sends in two empty vectors which are used for storing bits and a node index that indicates that the recursive call starts at the root node. The returned values from SC_Decode_Node are placed in three vectors: L, ucap and u. The only value of interest is vector u because it contains the decoded bits. The function removes the frozen bits from u, see figure 4.20, because they are useless from this point forward. This is done with the help of function getReliabilitySeq, that gets the reliability sequence of size N and places it in Qn, see section 4.3.2. To only store the information bits the functions collects the N − K most reliable positions from Qn and collect the bits values in u on these given positions. These bit values are placed into c_bits which is later returned as the function end.
function c_bits = SC_Decode(d_bits, N, K)
[L ucap u] = SC_Decode_Node(d_bits, [], [], N, K, 1); Qn = getReliabilitySeq(N); c_bits = u(Qn(N-K+1 :end )); end
Figure 4.20: MATLAB code for SC_Decode
45 4.6.3 SC_Decode_Node.m
This is the function where the actual decoding happens. It builds on recursion and operates on a perfect binary search tree, meaning that every node, except leaf nodes, have exactly two children. The recursive function has four node states: leaf state, left state, right state, and the up/return state. The leaf state checks if the node is a leaf and uses the belief to set the u value. The left and right states respectively call the left and right children nodes. The up/return state will send the calculated value up to its parent node. Each recursive call uses six in-parameters and it has three output values. In-parameters are: • L - Vector containing the beliefs for the transmitted bits. • ucap - Vector containing bit values as they are represented in the virtual channels. These values will change as the recursion unrolls itself. • u - Vector containing the set bit values, when the root node is finished this contains the complete decoded transmission. • N - Size of the received bits. • K - Size of received information bits. • i - Index for which node the recursion is currently at. Output values are: • L - Vector containing the updated beliefs by this node. • ucap - Vector containing the updated bit values by this node. • u - Vector containing the currently decoded bit values updated only by leafs. The first decision made in the function is whether or not the current node is aleaf,see figure 4.21. This is done by checking if the index i is larger than the size of transmitted bits N. If so, this means the node is a leaf and the function has to verify whether or not this leafs corresponding bit position is a frozen bit or not. Its position is collected by calculation (i − (N − 1)). If the leaf corresponds to a frozen bit position, the bit value is
46 set to 0, otherwise it is set according to its belief value where L < 0 : 1 || L ≥ 0 : 0. The decided bit value is appended to ucap and u.
%Leaf if i ≥ N Qn = getReliabilitySeq(N); f_pos = Qn(1:N-K); %Frozen if any(f_pos == (i-(N-1))) ucap(END+1) = 0; u(END+1) = 0; %Not Frozen else if L(1) ≥ 0 ucap(END+1) = 0; u(END+1) = 0; else ucap(END+1) = 1; u(END+1) = 1; end end end
Figure 4.21: MATLAB code from SC_Decode_Node, leaf operation
If the index is less than N this means that the node is not a leaf and has to split up L such that half the values are sent to the left child and the other half to the right child, see figure 4.22. Which values to send to the left child is done be the SplitLeft-function, definition in section 3.7.2. The recursive call to the left child will then include the beliefs picked from SplitLeft, ucap, u, N, K and i × 2 which sets the index to left child of the node. The returned values are put into leftL, ucapL and u. As the left child is finished, the function continues to the right child. Parameters sent to the right child are ucap, u, N, K, (i × 2) + 1 and beliefs from L depending on the output of function SplitRight, see section 3.7.3 for definition of SplitRight. The returned values from right child are put into rigthL, ucapR and u. ucapR and rightL represent the set bits by right child and their corresponding updated beliefs.
47 Finally the function combines the results received from its children, left and right, to send up the tree to its parent, see section 3.7.4 for definition. The operation is done by adding every position from ucapL with corresponding ucapR and performing a mod2- operation on the result.
%Not Leaf else %Split L in half: a & b a = L(1 :end /2); b = L(end/2+1 :end );
%Left [leftL ucapL u] = SC_Decode_Node(SplitLeft(a,b), ucap, u, N,K, i*2);
%Right [rightL ucapR u] = SC_Decode_Node(SplitRight(a,b,ucapL), ucap, u, ... N, K, (i*2)+1);
%Up ucap = [mod(ucapL+ucapR, 2) ucapR]; L = [leftL rightL]; end
Figure 4.22: MATLAB code from SC_Decode_Node, left/right/up part. Functions SplitLeft and SplitRight are code derived from equation 3.7 and 3.9
4.7 Simulation
The main file for the simulation is testEnvironment.m. At the start of the program a random seed is set, this is done to ensure that all simulations can be repeated with the same result each time it is run. After the random seed is set the other variables are initialised, see figure 4.23. Apart from variables associated with CRC, all values are parameters to define the scope of the simulation. For every loop, block sizes and signal strength is set. The test environment itself is build using three encapsulated for-loops, from inside out: subframe-loop, signal-strength-loop and block-size-loop.
48 rnti = 123; crcSize = 24; crcXor = dec2bin(rnti, crcSize) - '0'; crcType = 'crc24c';
nSubframes = 1000; minSNR = -1; stepSNR = 0.25; maxSNR = 4;
%power(2, n) to get blocksize. start_n = 7; end_n = 10;
Figure 4.23: MATLAB code from variable initialisation in testEnvironment
At the innermost for-loop, subframe-loop, the message to be sent is prepared. Its length is calculated using N,K and crcSize, see figure 4.24, where N and K will increase for each outermost loop cycle. N and K respectively represent the transmission block size and information bits size.
N = trBlockSize; K = N/2; %Generate Message a = randi([0 1], 1, K-crcSize);
Figure 4.24: MATLAB code where the message is generated testEnvironment
The message bits are then sent to the Polar encoder, see section 4.3, and the output is placed into encodedBits variable. To simulate the encoded bits being transmitted, noise is added to the message by using a AWGN channel simulation. This is done by converting the encodedBits to symbols, see section 2.4, and then adding random generated noise represented by complex values which creates an offset. The offset is mainly dependent on signal strength and N/K-ratio. The receiver side of the simulation passes the received encoded bits to the decoder, see
49 section 4.6, and the output is placed in trBlock and crcFlag. crcFlag is stored in a matrix called crcMatrix which holds the crcFlag for each subframe. When all the nSubframes have been executed for the current signal strength and block size, BLER is calculated, see code snippet 4.25 and BLER definition in section 2.10.
ResultBLER(iRES, n-start_n+1) = ... sum(crcMatrix(iSNR,1:nSubframes)>0)/nSubframes;
Figure 4.25: MATLAB code BLER calculation
4.8 Summary
In this chapter the overall implementation of this thesis was described. The main focus was on the NR implementation of Polar Codes and the rate matching that comes with it. The Polar decoding algorithm described in the implementation was Successive Cancellation. The simulation environment was described, explaining the different parameters that are set for the simulations.
50 5 Results
5.1 Introduction
This chapter explains and evaluates the results from the simulations where Polar Codes is used with the Successive Cancellation algorithm. The simulations have been configured with different parameters to evaluate the desired parts of the Polar Codes implementation. The following sections will evaluate Polar Codes on its decoding performance using different sizes with and without different rate matching techniques.
Finally Polar Codes is compared to the existing control channel algorithm used in LTE, Convolutional Codes.
5.2 Polar Codes: Successive Cancellation performance
The simulation results in figure 5.1 show that the performance of Polar Codes using SC as decoding algorithm varies dependent on block size. The result shows that the simulation where block size (1024, 512) was used performs better than Polar Codes with smaller block sizes. For 1% BLER, the block size of (1024, 512) compared to block size (512, 256), has a code gain of almost 0.5 dB. This means that block size (1024, 512) can reach the same decoding performance as block size (512, 256) with 0.5 dB less signal strength. Compared to the block sizes, (256, 128) and (128, 64) the code gain is more than 0.5 dB.
This behaviour can be explained with the structure of Polar Codes, where a larger block size will lead to more polarised virtual channels as explained in section 3.3.2. More polarised virtual channels lead to a bigger difference between information bits and frozen bits, making it easier to successfully decode the received bits.
51 Figure 5.1: SC block size performance. Polar(N,K), subframes: 1000, CRC: crc24c
5.3 Rate matching with repetition
Figure 5.2 represents a simulation where the transmission is using rate matching with repetition, see section 3.4 for definition. The graph also includes results from simulations done without rate matching to show the performance gained when using rate matching with repetition.
Simulations ran with rate matching are displayed as solid lines and without rate match- ing are represented with dotted lines.
To simulate repetition, during rate matching a redundancy of bits is created. The bits which are sent over the channel contains two copies of each encoded bit after rate matching.
52 Figure 5.2: No rate matching vs repetition. Dotted lines are without rate matching and solid lines are with repetition. Polar(N, K) E , Subframes: 1000, CRC: crc24c.
When comparing the block sizes using repetition from 10% down to 0.1% BLER, one can see that block size (1024, 512) has the best performance. The largest code gain, which is nearly 1.5 dB, can be seen between (1024, 512) and (128, 64) at 0.1% BLER. As explained in the earlier section, this depends on Polar Codes structure as it achieves better performance when used on larger block sizes.
In figure 5.2 it is also clear that from 2.5 to 4 Eb/N0 each block size using repetition has a better BLER performance compared to the same block size without repetition. For (1024, 512) it is a code gain of 0.5 dB at 0.1% BLER.
One can see that at approximately 0.5% block error rate, (512, 256) behaves unexpected which causes it to perform worse than (128, 64). These errors though can be neglected as
53 they yield an error of about (20/1000) erroneous blocks on a 1000 subframes simulation.
5.4 Rate matching with puncturing
Rate matching with puncturing will result in smaller block sizes that are sent over a channel as described in section 3.4. For the evaluation of the performance of Polar Codes using rate matching with puncturing, simulations were performed by puncturing 10% of the bits before transmission. The results of these simulations can be seen in figure 5.3, where simulations using puncturing are represented with solid lines, and simulations without rate matching are represented with dotted lines. The simulation results show that for all four block sizes the simulations without rate matching perform slightly better. The code gain for simulations without rate matching compared to simulation using puncturing is up to 0.25 dB at 1% BLER. This result is expected because removing bits logically makes it more difficult to restore the original message bits. The performance loss when using puncturing is however not that great and if a stronger signal is available, performance improvements could be achieved with this technique.
54 Figure 5.3: No rate matching vs puncturing. Dotted lines are without rate matching and solid lines are with puncturing. Polar(N, K) E , Subframes: 1000, CRC: crc24c.
5.5 Rate matching with shortening
For the simulation of the effect that shortening has on the BLER performance, this the- sis uses a shortening of 10%. This means that 10% of the bits are removed from the transmission during rate matching, see section 3.4. In figure 5.4 the results from shortening compared to simulations without rate matching is presented. Simulations using shortening are represented with solid lines while simulations without rate matching is represented by dotted lines. By comparing the same block size to each other it is clear that shortening has a large negative impact on the performance of Polar Codes. For block size (1024, 512) at 1% BLER there is a code gain of -0.75 dB. This is expected though since shortening removes important bits to match the desired block size.
55 Although performing worse than a transmission not using rate matching, shortening should still be used. When a strong signal is available, shortening allows the transmission to send less bits and still restore the message at the receiver side.
Figure 5.4: No rate matching vs shortening. Dotted lines are without rate matching and solid lines are with shortening. Polar(N, K) E , Subframes: 1000, CRC: crc24c.
5.6 Polar Codes vs Convolutional Codes
In the previous sections Polar Codes has been tested using different block sizes to determine whether or not its performance grows as the block sizes increases. In this section Polar Codes is compared against LTEs control channel algorithm, Con- volutional Codes, to see how it performs compared to the algorithm its replacing. In contrast to the earlier simulations, this one was ran in Tieto’s LTE simulation envi- ronment. Because the scope of this thesis did not include development and implementation
56 of Convolutional Code, an already existing implementation from Tieto was used.
Figure 5.5: Polar Codes versus Convolutional Codes, Subframes = 1000, transmission block size = 960, signal strength = [-5:0.5:5], message sizes(Left-to-right): 88, 144, 176, 208, 256, 328, 392, 472, 536, 616. Same color & marker = same message size
As can be seen in figure 5.5, 10 simulations were ran for both Convolutional Codes and Polar Codes. They used the same environment but differ in which rate matching was used. Polar Codes uses the rate matching implemented in this thesis which follows the 3GPP standard for NR [12]. Convolutional Codes uses the rate matching implemented by Tieto in their environment, the rate matching algorithm for Convolutional Codes follows the 3GPP standard for LTE [11]. In figure 5.5 the same block sizes are represented with the same colours. Polar Codes are displayed by a solid line while Convolution Codes are displayed as dotted line. As can be seen in figure 5.5 Polar Codes has better BLER-performance than Convolu- tional Codes on all tested block sizes. When looking at 1%-BLER one gets an approximate average of 0.4 dB code gain for Polar Codes.
57 5.7 Summary
This chapter explained and evaluated the simulation results that were generated from the different simulations. First the performance of Polar Codes was evaluated using different rate matching settings, after which the performance of Polar Codes was compared against Convolutional Codes. The results shows that Polar Codes performs better with larger block sizes for all the different settings tested. This is a reasonable result that can be explained withthe polarisation of channels which is the core structure of Polar Codes. Rate matching was used to enlarge the block size to double the polar encoded bits. The results show that a slight code gain can be achieved with this technique. When a block size is larger than the desired transmission block size, rate matching can be used in two different ways, puncturing or shortening. The performance of these techniques is expected to be less, compared to not reducing the block size. This loss in reliability when sending smaller block sizes could lead to performance gain when a strong signal is available. Puncturing shows the most promising results with a code gain of about -0.25 dB at 1% BLER whereas shortening losses more performance with about -0.75 dB code gain. Lastly Polar Codes is compared with Convolutional Codes using different message sizes for a set transmission block size. The results show that Polar Codes has an approximate average of 0.4 dB code gain over Convolutional Codes.
58 6 Conclusion
6.1 Introduction
This chapter contains the final conclusions for this thesis divided into two sections: Thesis evaluation and Future work. Thesis evaluation will explain the work performed in this thesis and the findings from the results achieved from the simulations. Future work, explains how research in this thesis could be continued to improve the implementation and reach better results by using a more complete simulation environment and by improving the algorithms used.
6.2 Thesis evaluation
This thesis evaluated the performance of Polar Codes. Polar Codes can use a variety of different decoding algorithms and after careful consideration Successive Cancellation was chosen as the algorithm to develop and implement for this thesis. Successive Cancellation is one of the first proposed algorithms and has many adoptions making it an interesting algorithm to evaluate. After developing and implementing Polar Codes using the Successive Cancellation al- gorithm, its performance was measured within a simulation environment. Polar Codes was evaluated using a CRC: crc24c according to the 3GPP standard [12] and the simulation was ran for 1000 subframes. The results from the simulation shows that Polar Codes performs better for larger block sizes. Polar Codes was also evaluated for different rate matching techniques, repetition, punc- turing and shortening. These techniques are defined in the 3GPP standard [12]. Repetition is a rate matching technique used when more redundancy for the transmitted bits is desired and therefore the encoded bits will be sent multiple times within the same transmission block. The results from the simulation using repetition show that there is a
59 small code gain when the block size is doubled. When a smaller block size is desired puncturing or shortening can be used. The simu- lations ran for this thesis evaluated the puncturing and shortening when the block size was reduced by 10%. Puncturing shows a small performance loss compared to no reduction of block size. Shortening show a significant larger performance loss compared to puncturing with the same amount of reduction. These performance losses might not be desired in most cases, but when a strong signal is available, higher transfer rates might be achieved when reducing the amount of transferred bits. Lastly the performance of Polar Codes is compared to the performance of Convolutional Codes. The evaluation was done by implementing Polar Codes in an LTE simulation environment where its performance could be measured and compared to the performance of Convolutional Codes. The results show that Polar Codes performs slightly better in terms of different block sizes and rates that were simulated and evaluated.
6.3 Future work
There are many different research paths that can be chosen for future work. One that is ranked high on our list is to implement a simulation environment more similar to a NR-network. This would make the comparison between Convolutional Codes and Polar Codes more fair, since Polar Codes in this thesis is tested in an environment meant for LTE-simulations. Because implementing a whole 5G-simulation environment might be too tough, it would be interesting to at least implement an Interleaving-module and the missing part of the Rate Matching(Interleaving of coded bits). Another approach would be to implement more Polar decoders to test their performance against each other, with a final comparison to Convolutional Codes. Of course the first algorithm to implement would be Successive Cancellation List (SCL) which has been proven to have a significant code gain compared to Successive Cancellation. Unfortunately time did not permit the implementation during this thesis.
60 Another interesting research point would be to implement SC in a hardware suitable programming language. All implementations done during this thesis has been made in MATLAB. Implementing SC in for example C would allow improvement compared to our implementation of SC done in MATLAB. An interesting aspect to evaluate would be time and memory consumption between MATLAB implementation and C implementation.
61 References
[1] E. Arikan. Channel polarization: A method for constructing capacity-achieving codes for symmetric binary-input memoryless channels. IEEE Transactions on Information Theory, 55(7):3051–3073, July 2009. ISSN 0018-9448. doi:10.1109/TIT.2009.2021379.
[2] Tieto. About Tieto, 2019. URL https://www.tieto.com/en/about-us/ our-company/. [Accessed February 2019].
[3] Stefania Sesia, Matthew Baker, and Issam Toufik. LTE - The UMTS Long Term Evo- lution : From Theory to Practice., volume 2nd ed. Wiley, 2011. ISBN 9780470660256.
[4] Erik Dahlman, Stefan Parkvall, and Johan Sköld. 5G NR: The Next Generation Wireless Access Technology. Academic Press, 2018. ISBN 9780128143230.
[5] Various. Additive white gaussian noise, 2018. URL https://en.wikipedia.org/ wiki/Additive_white_Gaussian_noise. [Accessed February 2019].
[6] Various. Rayleigh fading, 2019. URL https://en.wikipedia.org/wiki/Rayleigh_ fading. [Accessed February 2019].
[7] Various. Random waypoint model, 2019. URL https://en.wikipedia.org/wiki/ Random_waypoint_model. [Accessed February 2019].
[8] Tutorialspoint. Wi-fi - radio modulation, . URL https://www.tutorialspoint.com/ wi-fi/wifi_radio_modulation.htm. [Accessed March 2019].
[9] Tutorialspoint. Digital communication - phase shift keying, . URL https: //www.tutorialspoint.com/digital_communication/digital_communication_ phase_shift_keying.htm. [Accessed March 2019].
[10] C. E. Shannon. Communication in the presence of noise. Proceedings of the IRE, 37 (1):10–21, Jan 1949. ISSN 0096-8390. doi:10.1109/JRPROC.1949.232969.
[11] 3GPP Technical Specification 36.212. Evolved Universal Terrestrial Radio Ac- cess (E-UTRA); Multiplexing and Channel Coding (FDD), 15.4.0 edition, Jan- uary 2019. URL https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=2426.
[12] 3GPP Technical Specification 38.212. NR; Multiplexing and channel coding, 15.4.0 edition, January 2019. URL https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId=3214.
[13] I’MTeck. What are turbo codes?, 2016. URL https://blogrecherche.wp.imt.fr/ en/2016/09/16/what-are-turbo-codes/. [Accessed February 2019].
62 [14] P. Elias. Error-free coding. Transactions of the IRE Professional Group on Information Theory, 4(4):29–37, Sep. 1954. ISSN 2168-2690. doi:10.1109/TIT.1954.1057464.
[15] Various. Block error rate, 2018. URL https://en.wikipedia.org/wiki/Block_ Error_Rate. [Accessed February 2019].
[16] Mathworks. Matlab, 2019. URL https://mathworks.com. [Accessed February 2019].
[17] Christer Frank. Kodning för felkontroll. Lund : Studentlitteratur, 2004. ISBN 91-44- 03664-7.
[18] Various. Binary symmetric channel, 2018. URL https://en.wikipedia.org/wiki/ Binary_symmetric_channel. [Accessed February 2019].
[19] I. Tal and A. Vardy. List decoding of polar codes. IEEE Transactions on Information Theory, 61(5):2213–2226, May 2015. ISSN 0018-9448. doi:10.1109/TIT.2015.2410251.
[20] B. Yuan and K. K. Parhi. Architecture optimizations for bp polar decoders. In 2013 IEEE International Conference on Acoustics, Speech and Signal Processing, pages 2654–2658, May 2013. doi:10.1109/ICASSP.2013.6638137.
[21] A. Elkelesh, M. Ebada, S. Cammerer, and S. ten Brink. Belief propagation list decod- ing of polar codes. IEEE Communications Letters, 22(8):1536–1539, Aug 2018. ISSN 1089-7798. doi:10.1109/LCOMM.2018.2850772.
[22] H. Aurora, C. Condo, and W. J. Gross. Low-complexity software stack decoding of polar codes. In 2018 IEEE International Symposium on Circuits and Systems (ISCAS), May 2018. doi:10.1109/ISCAS.2018.8351832.
[23] D. Guan, K. Niu, C. Dong, and P. Zhang. Successive cancellation priority decoding of polar codes. IEEE Access, 7:9575–9585, 2019. ISSN 2169-3536. doi:10.1109/ACCESS.2019.2890838.
[24] Thomas H. Cormen. Introduction to Algorithms., volume 3rd ed. The MIT Press, 2009. ISBN 9780262033848.
63