This is not a specific physical channel, but this sequence (variation of the sequence) are used in many way to generate a specific sequence itself (e.g, Downlink Reference Signal) or to scramble the data of a specific channel. The Pseudo-Random Sequence used for LTE is a type of Gold Sequence defined as follows in 36.211 7.2 Pseudo-random sequence generation. (If you are not familiar with the concep of Gold Sequence, refer to Gold Code page)

The picture below is the definition from 36.211 clause 7.2, with the c_init formulas of a few channels attached. Only the initial value of the second m-sequence changes from one use to another, and that single number decides the whole output.

36.211 clause 7.2. The first m-sequence x₁ always starts from 1 followed by 30 zeros. The second m-sequence x₂ starts from the 31 bits of c_init, and the output c(n) is taken after N_C = 1600 steps.

Followings are the list of topics to be discovered in this page.

• What is this used for ?
• How to implement ?
• Matlab Communication Package
• srsLTE
• My own MatLab code
• Code from Victor Ivanov
• Example Sequences
• Special Chat with Victor : LTE Pseudo Random Sequence in terms of Gold Code Concept
• Reference

What is this used for ?

The same generator serves many channels, so the useful question is what makes one use different from another. The answer is the initial value c_init: each channel builds it from its own mix of the cell identity, the slot number, the RNTI and other parameters.

What are we use this for ? There are several different application for this sequence as listed below.

• Generation of Downlink Reference Signal : Two of this Pseudo Random Sequence (Gold Sequence) is used
• Scrambling of PDSCH
• Scrambling of PMCH
• Scrambling of PDCCH
• Generation of PUSCH DMRS (e.g, PUSCH DMRS - 1RB)

The table below lists the c_init of the most common uses, from 36.211 v19.3.0. For the downlink reference signal, one sequence gives two bits per QPSK symbol, c(2m) and c(2m+1), rather than two separate sequences.

Two patterns stand out. The PCFICH, the PHICH and the CRS multiply by (2N_ID^cell + 1), so their sequences differ between neighbour cells. The data channels put the RNTI in the top bits, so two UEs in one cell get different sequences. The slot term changes the sequence from subframe to subframe, which spreads inter-cell interference over time.

• One generator for many channels : only c_init changes.
• Cell ID in every c_init : neighbour cells get different sequences.
• RNTI in the data channels : each UE gets its own scrambling.

How to implement ?

I will show you a couple of different ways of implementing this pseudo random sequence here. Depending on the language that you use and your programming style, you would have a little bit different code. Matlab communication package and srsLTE API is verified code, but my MatLab code is not verified but I hope it is written correctly.

• Matlab Communication Package
• srsLTE
• My own MatLab code
• Code from Victor Ivanov  

All four implementations below compute the same two recursions from 36.211 clause 7.2. They differ in memory use and in how much of the arithmetic they hide in a library, and the section Example Sequences checks that they agree.

Matlab Communication Package

If you have access to Matlab Communication Toolbox, you can implement this sequence as shown below. (This Matlab code clip is from the book : Understanding LTE with Matlab)

comm.GoldSequence set up for 36.211 clause 7.2. The polynomial vectors encode x³¹ + x³ + 1 and x³¹ + x³ + x² + x + 1, and 'Shift', 1600 is N_C.

The polynomial vectors list the coefficients from x³¹ down to x⁰. So [1 zeros(1, 27) 1 0 0 1] is x³¹ + x³ + 1, the recursion of x₁, and [1 zeros(1, 27) 1 1 1 1] is the recursion of x₂. The second initial condition comes from an input port, so the same object can take a new c_init for every call.

srsLTE

The srsLTE code below is the direct form of the definition. It stores the full arrays x₁ and x₂ of length N_C + length + 31, runs both recursions, and then adds the two arrays from index N_C.

Following is the implementation in srsLTE.

The seed bits fill x₂(0) to x₂(30) with the least significant bit first, which matches c_init = Σ x₂(i) 2ⁱ. The expression "+ +x2[n+1]" contains a unary plus, which C accepts, so the line still adds the four terms of the x₂ recursion.

My own MatLab code

Following is the Matlab code that I wrote using Matlab default function only. This would be very inefficient at machine level. You may not see this kind of implement at professional code example. But I wrote the code to make it look as closer to the way described in 3GPP document as possible. The purpose of this code is to give you better understanding of the 3GPP spec.

 

clear all;

 

% Initial condition of the polynomia x1(). This is fixed value as described in 36.211 7.2

x1_init = [1 0 0 0 0 0 0 0 0 0 ...

           0 0 0 0 0 0 0 0 0 0 ...

           0 0 0 0 0 0 0 0 0 0 ...

           0];

 

% Initial condition of the polynomia x2().

% This is supposed to be used as c_init as described in 36.211 7.2

% But for simplicity, I just se the arbitrary value for now

x2_init = [0 0 0 0 0 0 1 0 0 0 ...

           0 0 0 0 0 0 0 0 0 0 ...

           0 0 0 0 0 0 0 0 0 0 ...

           0];

 

% Mpn is the length of the final sequence c()

Mpn = 12*10;

 

% Nc as defined in 36.211 7.2

Nc = 1600;

 

% Create a vector(array) for x1() and x2() all initialized with 0

x1 = zeros(1,Nc + Mpn + 31);

x2 = zeros(1,Nc + Mpn + 31);

 

% Create a vector(array) for c() all initialized with 0

c = zeros(1,Mpn);

 

% Initialize x1() and x2()

x1(1:31) = x1_init;

x2(1:31) = x2_init;

 

% generate the m-sequence : x1()

for n = 1 : (Mpn+Nc)

   x1(n+31) = mod(x1(n+3) + x1(n),2);

end;

 

% generate the m-sequence : x2()

for n = 1 : (Mpn+Nc)

   x2(n+31) = mod(x2(n+3) + x2(n+2) + x2(n+1) + x2(n),2);

end;

 

% generate the resulting sequence (Gold Sequence) : c()

for n = 1 : Mpn

    c(n)= mod(x1(n+Nc) + x2(n+Nc),2);

end;

 

 

% Following has no meaning in practice, but I just plotted the result just to give you

% overall pattern

 

subplot(3,1,1);

stem(x1);xlim([1 length(x1)]); ylabel('x1(n)');

 

subplot(3,1,2);

stem(x2);xlim([1 length(x2)]); ylabel('x2(n)');  

 

subplot(3,1,3);

stem(c);xlim([1 length(c)]); ylabel('c(n)');

 



 

 

MATLAB indexes arrays from 1, so x1(1) in the code is x₁(0) in the specification, and c(n) = x1(n+Nc) + x2(n+Nc) with n = 1 is c(0) of the specification. The code sets x2_init with a single 1 in the 7th position, which is c_init = 2⁶ = 64. The plot above shows the long x₁ and x₂ arrays and the 120 output bits c(n).

Code from Victor Ivanov

Following is the code written by Victor Ivanov (vic.m.ivanov[at]gmail.com )  and shared here with permission by him. Depending on your background, it may be a little bit difficult to understand comparing to the two other examples shown above. But in terms of shift register logic this code would be more relavant. That is, this code would better represent the hardware implementation of the sequence.

Following is the comments from Victor when he was sharing the code with me.  I always like to read some comments from experts, coming directly out of his mind without considering much on formal writing. Once we try thinking of formal writing, it tend to dry and less lively :).  I hope this give some insight for other readers as well.

Having looked at the examples, it struck me that both the Matlab as well as the one from srsLTE, while easy to understand, use a lot of memory as they allocate space for at least (Nc + Mpn) to perform the computation after which only the last Mpn elements are taken into account. They both make use of traditional additions making them slow. You've already put a disclaimer on that so that's ok. But more importantly, with the hardware based implementation of gold sequence generation using LFSRs (explained here: GoldCode ) initially I found it difficult to relate how the 3GPP examples fit together with the LFSR logic.

So I thought you might be interested in adding the following C function that I quickly drafted to your page for the scrambling sequence generation. It can allocates memory for only Mpn bits and works entirely with bitwise operations making it at least twice and up to several times faster to compute the scrambling sequence 'c'.

Each m-sequence here is a 31-bit register. Bit 0 holds x(n) and bit 30 holds x(n+30), so the feedback x₁(n+31) is bit 0 XOR bit 3, and the register shifts right with the feedback entering at bit 30. The register form needs only the output array, which is why it saves the N_C + length words of the array versions.

• Four implementations, one definition : 36.211 clause 7.2.
• Seed bit i is x₂(i) : least significant bit first.
• Register form : no arrays of length N_C needed.

Example Sequences

Do the four implementations really produce the same bits? A Python version of the 36.211 definition and a Python version of the register code from Victor Ivanov give identical output for every c_init tried, including 0, 1, 64, 12345 and 2³⁰ + 7.

The table below gives the first 16 bits c(0) to c(15) for a few c_init values. The value 1 is the PDCCH of PCI 1 in slot 0, the value 1537 is the PCFICH of the same cell, and 24579 is the CRS of PCI 1 in symbol 0 of slot 0 with normal cyclic prefix. The value 1638401 is the PDSCH of RNTI 100 in PCI 1, codeword 0, slot 0.

Values 0 and 1 differ only from c(8) onward, although their c_init differ in one bit. That is the reason for N_C = 1600: without the 1600 warm-up steps, two close c_init values would give sequences that agree for many bits. Over 10000 bits of c_init = 1, the output holds 4822 ones, close to the half that a random-looking sequence should have.

The warm-up can be measured. Without it, with N_C = 0, the sequences for c_init = 0 and c_init = 1 differ in only 10 of their first 100 bits, at positions 0, 31, 59 and a few later ones. With N_C = 1600 they differ in 42 of the first 100 bits, close to the 50 expected from two unrelated sequences.

The same check works between cells. Mapping 0 to +1 and 1 to -1, the correlation over 1000 bits is 44 between the PDCCH sequences of PCI 1 and PCI 2 in slot 0, and 62 between their PCFICH sequences, c_init = 1537 and 2562. Both are small against the 1000 that identical sequences would give, so a UE that descrambles with the wrong cell gets noise rather than a valid channel.

• All implementations agree : checked for several c_init values.
• N_C = 1600 decorrelates close seeds : one changed bit changes the whole output.
• About half the bits are 1 : 4822 of 10000 for c_init = 1.

Special Chat with Victor : LTE Pseudo Random Sequence in terms of Gold Code Concept

I had some chat with Victor in email about LTE Pseudo Random Sequence in terms of Gold Code Concept and I thought the comment / explanation can be helpful (very practical explanation) for other readers, especially for the person like me who is not a real expert on this low layer implementation. So I decided to share the chat here with his permission of course.

[Victor] (...) it's not immediately obvious why it works and how it fits with the Gold Sequence LFSR diagram",

[Sharetechnot] Sorry if I confused you, in my understanding LFSR, m-Sequence, Gold Sequence is a TYPE of sequence generation algorithm which has a certain kind of characteristics, they do not indicate any specific sequence of numbers.

Gold Sequence is generated by combining two m-Sequence (m-Sequence is a type of LFSR) as illustrated in my Gold Sequence page (number of shift register and wiring may vary as long as it meets a certain set of characterstics).

In LTE PRS, I think c[] is a type of Gold Sequence which is made up of two m-Sequence (x1[], x2[]).

[Victor] No problem at all. I too have mostly been using it to understand / study it. My research is actually in computer microarchitecture for 5G. It's difficult to say how it's currently implemented in real hardware as a lot of it is proprietary information of chip manufacturers and hardly any of it is available in the public domain.

Your understanding of the Gold Sequence is correct. My confusion did not come from your Gold Code diagram itself, but the question I was trying to answer to myself was "How do I implement the LTE sequence generator as gold code in hardware with LFSRs?". Which was difficult to answer from the Matlab and srsLTE code as they do not describe LFSR logic but rather in-memory computation of arrays.

But since Gold Code does, in fact, combine two m-sequences to generate the Gold sequence and each m-sequence can be easily implemented (in hardware) with a linear feedback shift register (LFSR), like the two on your Gold Code page. And the way we describe which individual bits are used in the feedback logic of the LFSR is by generator polynomials. In fact, it's the generator polynomials that tells us exactly what the wiring of the LFSR is. In the 3GPP LTE PHY specs, the two equations for x1(n+31)=... and x2(n+31)=... essentially describe (in a non-obvious way) the two generator polynomials for the two m-sequences that the LTE Gold Code generator uses:

    G(m1) = x^3 + 1              (derived from x1(n+31)=...)

    G(m2) = x^3 + x^2 + x^1 + 1  (derived from x2(n+31)=...)

Once we know these, along with the fact that in 3GPP LTE the two m-sequences are 31 bits wide (as specified in chapter 7.2) we can go back to your Gold Code circuit diagram and create the same diagram with 31 [D] cells (each [D] cell stores a single bit) and making our feedback wiring based on based on the above generator polynomials (see attached diagram for the LTE Gold Code generator).

You could have different wiring and it would still produce a valid Gold Code sequence, but if the wiring is different it will produce a different sequence. Thus, there can only be one exact wiring in LTE that can be used which is described by the above generator polynomials.

But to have the circuit actually generate any bit sequence at all it must have an initial value. For example, if the Gold Code circuit that you have on your page had a value of 0 stored in each [D] cell for both the top and bottom LFSR, then the output for c[n] will always be 0, regardless of how many clock cycles pass and it won't generate any sequence at all.

This is why 3GPP specifies the _initial_ values for the m1 and m2 sequences. Assuming the LTE PRS generator is implemented with two shift registers (as in your Gold Code diagram), the initial value for the 1st m-sequence LFSR is always set to 0x1, meaning that all the left-most 30 [D] cells of the shift register will hold a value of 0, and the right-most [D] cell will have a value of 1.

The _initial_ value of the 2nd m-sequence LFSR is the binary value for c_init which varies for each channel (xPDSCH, xPDCH, etc) and device, and the way it's computed is described in the specs for each channel.

And before we start taking the values for c[n] we let the circuit shuffle around for Nc=1600 cycles to induce extra randomness for the initial state. We can then start taking the bit values coming out of the circuit for c[n].

The example binary number (00...101101) that I gave in my previous email is completely arbitrary and not related to LTE specifically, but it serves well to demonstrate how the code works and how it relates to the Gold Code circuit that you have (which for me was difficult to comprehend initially). And since the code uses binary shift operators, we can immediately see how the two real shift registers of the Gold Code generator would behave (if implemented with LFSR logic).

In short, the chat reaches the same picture as the table in the first section. The wiring of both LFSRs is fixed by the two polynomials, the first register always starts from 1, and the only thing a channel chooses is the starting value of the second register.

• Gold sequence = two m-sequences XORed : x₁ and x₂ in 36.211.
• Fixed wiring, variable start : c_init is the start of the second register.
• N_C = 1600 warm-up : the output is taken after 1600 shifts.

Reference

[1] 3GPP TS 36.211 v19.3.0 - clause 7.2, Pseudo-random sequence generation, and the scrambling and reference-signal clauses listed in the table above