Physical Control Format Indicator Channel (PCFICH)

Introduction

'Channels' are used to differentiate different kinds of traffic on radio path. For example, data channels carry users traffic (Youtube, Skype data etc) and control channels carry signaling traffic to manage radio resources, setting up connection etc

The Physical Control Format Indicator Channel (PCFICH) is one of the control channels that works at physical layer. It is used to dynamically indicate the number of symbols to be used for PDCCH.

Why do we need PCFICH ? 

With the help of PCFICH channel, following scenarios are possible:

- Use less symbols for PDCCH if there are a few users with high data rates. Thus leaving more resource elements to be used for user plane data (PDSCH)

- Use more symbols for PDCCH if there are many users with lower data rates e.g VoIP calls in the cell, thus allowing more users capacity.

Signalled value

PCFICH signalled value depends on channel bandwidth. For channel bandwidth of 3MHz up to 20 Mhz it can carry value of 1, 2 or 3. But for 1.4 Mhz channel bandwidth it can carry value of 2, 3 or 4. Because in case of 1.4 Mhz bandwidth, there are few subcarriers in frequency domain.Therefore, more space is required in time domain to carry PDCCH symbols

Location of PCFICH symbols on Resource Grid

PCFICH occupies 16 resource elements in frequency domain.  These resource elements are divided into groups of four quadruplets distributed within first OFDMA symbol of each 1 ms subframe. The exact position of PCFICH can be measured from Cell ID and bandwidth using formula given in 3GPP spec 36.211 as below

Where
NRBSC = Number of frequency carriers per Resource block
NDLRB = Number of resource blocks per bandwidth
NcellID  = Physical Cell id

It may look complicated but lets try to understand it with simple example

Lets suppose
Physical Cell id = 20
Bandwidth = 10Mhz  (NDLRB = 50)

Then according to 3GPP Formula

k_Bar = (12/2).(20 mod 2*50) = 6*20 = 120

Then the four PCFICH mapping values are below 

120
120 + (50/2)*(12/2) = 270
120 + 2*(50/2)*(12/2)  = 420
120 + 3*(50/2)*(12/2) = 570

Visit LTE Resource Grid generator to validate above mapping values (Enter Cell id = 20 and Bandwidth = 10Mhz)
http://paul.wad.homepage.dk/LTE/lte_resource_grid.html 

Random Access Procedure in LTE

Background

When you switch on smartphone for the very first time, it will start searching for the network. There is a possibility that there are many networks or to put in other words , there are many frequencies from different operators available in the air to which UE (user equipment) can connect. Therefore, UE  needs to synchronize to each frequency and check whether this is frequency from the right operator to which it wants to connect to. UE does this by going through very initial synchronisation process. Once synchronized UE reads the master information block and System information blocks to check whether this is the right PLMN. Lets assume that it finds that PLMN value to be correct and so UE will proceed with reading System information block 1 and System information block 2. The next step is known as Random Access Procedure in which the network for the first time knows that some UE is trying to get access.

At this stage, UE does not have any resource or channel available to inform network about its desire to connect to it so it will send its request over the shared medium. Now there are two possibilities at this stage, either there are many other UEs in the same area (same cell) sending same request in which there is also a possibility of collision among the requests coming from various other UEs. Such random access procedure is called contention based Random access procedure. In second scenario, network can inform UE to use some unique identity to prevent its request from colliding with requests coming from other UEs. The second scenario is called contention free or non contention based random access procedure.

RACH preambles

The concept of RACH preamble though a little confusing is important in understanding the random access procedure.

When UE sends the very first message of random access procedure to some network, it basically sends specific pattern or signature which is called RACH preambles. The preamble value differentiate requests coming from different UEs. But if two UEs uses same RACH preambles at same time then there can be collision. There are totally 64 such patterns or signature available to the UE for the very first message of random access procedure and UE will decide any one of them randomly for contention-based random access procedure but for non-contention based procedure, actually network will inform UE about which one to use

In case, when UE goes from idle state to RRC connected state, there is no way for network to inform UE about which preamble out of 64 values should be used. Therefor UE has no choice but to use one of the preambles randomly which also result in possibility of collision if the same preamble is being used by another UE, provided the requests comes at same time (same frame)

In another scenario  if UE has to take handover to another eNB, in this case actually the UE can be informed about which preamble it can use, since UE is already in connected state

Steps of Random access procedure

Random access procedure consist of four steps explained below (Only contention based procedure is shown below)


Step 1: Msg1

  • UE selects one of the 64 available RACH preambles
  • Now UE also needs to give its own identity to the network so that network can address it in next step. The identity which UE will use is called RA-RNTI (Random access radio network temporary identity). Basically its not some value sent by UE but interestingly RA RNTI is determined from the time slot number in which the preamble is sent
  • If UE does not receive any response from the network, it increases its power in fixed step and sends RACH preamble again

Step 2: Msg2

  • eNodeB sends "Random Access Response" to UE on DL-SCH (Downlink shared channel) addressed to RA-RNTI calculated from the timeslot in which preamable was sent, as explained in step 1 (about RA-RNTI calculation)
  • The message carries following information 
    • Temporary C-RNTI: Now eNB gives another identity to UE which is called temporary C-RNTI (cell radio network temporary identity) for further communication
    • Timing Advance Value: eNodeB also informs UE to change its timing so it can compensate for the round trip delay caused by UE distance from the eNodeB
    • Uplink Grant Resource: Network (eNodeB) will assign initial resource to UE so that it can use UL-SCH (Uplink shared channel)

Step 3: Msg3 

  • Using UL-SCH, UE sends "RRC connection request message" to eNodeB
  • UE is identified by temporary C-RNTI (assigned in the previous step by eNodeB)
  • The message contains following
    • UE identity (TMSI or Random Value )
      • TMSI is used if UE has previously connected to the same network. With TMSI value, UE is identified in the core network 
      • Random value is used if UE is connecting for the very first time to network. Why we need random value or TMSI? Because there is possibility that Temp-CRNTI has been assigned to more than one UEs in previous step, due to multiple requests coming at same time (Collision scenario explained later)
    • Connection establishment cause: The shows the reason why UE needs to connect to network

Step 4: Msg4

  • eNodeB responds with contention resolution message to UE whose message was successfully received in step 3. This message is address towards TMSI value or Random number (from previous steps) but contains the new C RNTI which will be used for the further communication

Collision Scenario

The above example didn't consider any collision. Collision can occur because of following example scenario
  • Lets assume two UEs send same RACH preamble at same time in step 1
  • Same Temp C-RNTI and up-link grant will be received by two UEs in step 2
  • In step 3 eNodeB may be able to receive Msg3 from only one UE or none of them due to interference. 
  • In step 4 the UE which does not receive Msg4 from eNodeB will back-off after expiration of RACH specific timers. Possibility is also that none of them receive Msg4 
  • UE which receive msg4 will move to next step and decode RRC connection setup message


For more LTE call flows, please check out this tool

GPRS Tunneling Protocol (GTP) in LTE

Introduction

GPRS Tunneling protocol is an important IP/UDP based protocol used in GSM, UMTS and LTE core networks. It is used to encapsulate user data when passing through core network and also carries bearer specific signalling traffic between various core network entities. This protocol has several advantages which will be discussed later.


GPRS Tunneling Protocol Types



Why is GTP used in LTE?

  • It provides mobility. When UE is mobile, the IP address remains same and packets are still forwarded since tunneling is provided between PGW and eNB via SGW 
  • Multiple tunnels (bearers) can be used by same UE to obtain different network QoS
  • Main IP remains hidden so it provides security as well
  • Creation, deletion and modification of tunnels in case of GTP-C

GTP Interfaces in LTE

In LTE, version 2 is used for GTP-C and version 1 is used for GTP-U
In simple LTE network implementation, GTP-v2 is used on S5 and S11 interfaces and GTPv1 is used on S1-U, S5, X2-U interfaces (as shown below). In inter-RAT and inter PLMN connectivity, S3, S4, S8, S10, S12 and S16 interfaces also utilize GTP protocols

How GTP-U Works ?

GTP-U encapsulation of UE user plane traffic can be easily understood by taking any simple example. Lets see what happens when IP packet generated by UE reaches to eNodeB and is then forwarded to SGW.

Consider any application on UE creates an IP/TCP packet. This packet consist of actual data by application, TCP or UDP header and then IP field information which has source address of UE and destination address of application server (e.g. Facebook)

When the eNodeB receives this packet over air interface, it will put the IP packet inside GTP header which has information related to tunnel IDs. Then further, it is encapsulated inside UDP and IP header and forwarded as ethernet frame towards SGW. Here the IP header contains eNodeB IP as a source address and SGW IP as a destination address

GTP-C signalling messages

As GTP-Cv2 in LTE is used for tunnel management, some of the signalling messages are listed below which use GTP-Cv2 protocol 



Please check Table 6.1-1(3GPP TS 29.274) for more detailed list of GTP-C based messages.



System information block 2 (SIB2) in LTE

After initial cell synchronization process is completed, UE will read master information block which contains important information regarding downlink cell bandwidth, PHICH configuration and System frame number. Then UE can read System information block 1 and System information block 2 to obtain useful information related to cell access, SIB scheduling and radio resource configuration

System information block 2 carries radio resource configuration information which is common for all UEs.

SIB2 information can be divided in following sub categories
  • Random access channel (RACH) related parameters 
  • Idle mode paging configurations 
  • Uplink physical control channel (PUCCH) and shared channel (PUSCH) configurations 
  • Uplink power control and Sounding reference signal configurations 
  • Uplink carrier frequency / Bandwidth 
  • Cell barring information 

SIB2 Example

Example SIB2 info is shown below (Taken from UE logs). This SIB2 does not represent any real network

value BCCH-DL-SCH-Message ::= 
  message c1 : systemInformation : 
        criticalExtensions systemInformation-r8 : 
            sib-TypeAndInfo 
              sib2 : 
                  radioResourceConfigCommon 
                    rach-ConfigCommon 
                      preambleInfo 
                        numberOfRA-Preambles n40,
                        preamblesGroupAConfig 
                          sizeOfRA-PreamblesGroupA n32,
                          messageSizeGroupA b144,
                          messagePowerOffsetGroupB dB10
                       ,
                      powerRampingParameters 
                        powerRampingStep dB2,
                        preambleInitialReceivedTargetPower dBm-104
                       ,
                      ra-SupervisionInfo 
                        preambleTransMax n10,
                        ra-ResponseWindowSize sf5,
                        mac-ContentionResolutionTimer sf32
                       ,
                      maxHARQ-Msg3Tx 3
                     ,
                    bcch-Config 
                      modificationPeriodCoeff n8
                     ,
                    pcch-Config 
                      defaultPagingCycle rf64,
                      nB oneT
                     ,
                    prach-Config 
                      rootSequenceIndex 30,
                      prach-ConfigInfo 
                        prach-ConfigIndex 4,
                        highSpeedFlag FALSE,
                        zeroCorrelationZoneConfig 8,
                        prach-FreqOffset 3
                     ,
                    pdsch-ConfigCommon 
                      referenceSignalPower 11,
                      p-b 1
                     ,
                    pusch-ConfigCommon 
                      pusch-ConfigBasic 
                        n-SB 1,
                        hoppingMode interSubFrame,
                        pusch-HoppingOffset 6,
                        enable64QAM FALSE
                       ,
                      ul-ReferenceSignalsPUSCH 
                        groupHoppingEnabled FALSE,
                        groupAssignmentPUSCH 0,
                        sequenceHoppingEnabled FALSE,
                        cyclicShift 0
                     ,
                    pucch-ConfigCommon 
                      deltaPUCCH-Shift ds2,
                      nRB-CQI 1,
                      nCS-AN 0,
                      n1PUCCH-AN 36
                     ,
                    soundingRS-UL-ConfigCommon release : NULL,
                    uplinkPowerControlCommon 
                      p0-NominalPUSCH -100,
                      alpha al1,
                      p0-NominalPUCCH -100,
                      deltaFList-PUCCH 
                        deltaF-PUCCH-Format1 deltaF0,
                        deltaF-PUCCH-Format1b deltaF1,
                        deltaF-PUCCH-Format2 deltaF0,
                        deltaF-PUCCH-Format2a deltaF0,
                        deltaF-PUCCH-Format2b deltaF0
                       ,
                      deltaPreambleMsg3 1
                     ,
                    ul-CyclicPrefixLength len1
                   ,
                  ue-TimersAndConstants 
                    t300 ms200,
                    t301 ms200,
                    t310 ms500,
                    n310 n10,
                    t311 ms3000,
                    n311 n1
                   ,
                  freqInfo 
                    ul-CarrierFreq 20600,
                    ul-Bandwidth n50,
                    additionalSpectrumEmission 12
                   ,
                  timeAlignmentTimerCommon sf10240



Definition of important Parameters


Rach Configurations

numberOfRA-Preambles: Total number of random access preambles available for contention based random access. Since there are maximum 64 preambles sequences available, others could be reserved by eNB for Non-Contention based random access. Range of this parameter is 4 to 64
sizeOfRA-PreamblesGroupA: Total number of random access preambles sequences available within Group A. Preambles are divided into Group A and Group B. Group A preambles are intended for sending small packets and Group B preambles are intended for sending large packets. Range of this parameter is 4 to 60
messageSizeGroupA: Message size threshold for selecting preamble Group A in term of bits (56, 144, 208 or 256 bits)
messagePowerOffsetGroupB: Power offset for selecting preamble Group B (0, 5, 8, 10, 12, 15 or 18 dB)
powerRampingStep: power ramping step size with possible values of 0, 2, 4 or 6 dB
preambleInitialReceivedTargetPower: Preamble initial received target power with values from -120 dBm to -90 dBm with step size of 2 dBm 
preambleTransMax: Maximum number of preambles transmissions. Possible values are 3, 4, 5, 6, 7, 8, 10 ,20, 50, 100, 200.
ra-ResponseWindowSize: Duration of RA response window. RA response window size is in unit of subframes (2, 3, 4, 5, 6, 7, 8, or 10 subframes)
mac-ContentionResolutionTimer: Mac contention resolution timer in unit of subframes (8, 16, 24, 32, 40, 58, 56 or 64 subframes)
maxHARQ-Msg3Tx: Maximum number of HARQ retransmissions for message 3 of RACH process (contention-based Random access) with possible values from 1 to 8 in step of 1

BCCH Configurations

modificationPeriodCoeff: The value (2,4,6,8) of this parameter is multiplied with default DRX cycle (e.g. 320ms, 640ms) to generate the BCCH modification period. It is the period in which the change in SI is repeated to UEs so that the change in SI is acquired by UE.
BCCH modification period = modificationPeriodCoeff x idle mode DRX cycle
                                         

PCCH Configurations

defaultPagingCycle: The default DRX cycle in idle mode in unit of radio frames (rf64 means 640ms )
nB: This parameter value is used in finding the actual paging frames and paging occasions in RRC idle mode with the following formula
    SFN modT = (T/N) x (UE_ID mod N)

Where 
T = Drx cycle 
N = Min (T, nB)  (nB is broadcasted in SIB2) 
UE_ID = IMSI mod 1024

PRACH Configurations

rootSequenceIndex: RA preambles are generated from  Zadoff Chu sequence which consists of series of root sequences. Each root sequence can be cyclic shifted to obtain preamble sequence. Range of rootSequenceIndex is 0 to 837. 
prach-ConfigIndex: This parameter defines exactly when UE should send RACH in frequency/time grids  (Details TS36.211 Table 5.7.1-2)
highSpeedFlag: For high speed UEs , as this can impact the correlation between cycles
zeroCorrelationZoneConfig: The zero correlation zone is used to guarantee orthogonality of generated sequences. The value depends on particular condition in the cell
prach-FreqOffset: With this information cell informs UE and other neighbor cells know about which PRB is available for RACH access

PDSCH Configurations

referenceSignalPower: This defines the energy per resource element for the reference signal using a range from -60 to 50 dBm. 
p-b: It is used to calculate the power difference between PDSCH and Reference Signal. Value is from 0 to 3

PUSCH Configurations

n-SB: Number of subbands (range 1 to 4)
hoppingMode: Hopping mode can be inter-subframe, intra or inter-subframe
pusch-HoppingOffset: Offset values range from 1 to 98
enable64QAM: if 64QAM capable UE should use it (True or False)

groupHoppingEnabled: True or False
groupAssignmentPUSCH: Gives sequence shift pattern for group hopping (0 to 29)
sequenceHoppingEnabled: True or False
cyclicShift: Frequency shift for demodulation (0 to 7)

PUCCH Config

deltaPUCCH-Shift: 1,2 or 3
nRB-CQI: Number of PRBs per slot for PUCCH2 (0 to 98)
nCS-AN: Cyclic shift used for PUCCH1 (0 to 7)
n1PUCCH-AN: PUCCH to be used for HARQ (0 TO 2047)

Sounding Reference Signaling Configurations:

The uplink Sounding Reference Signal (SRS) is configured in terms of bandwidth and subframes

Uplink Power Control

p0-NominalPUSCH: It impacts the calculation of PUSCH transmit power and applicable to non-persistent scheduling only (-126 to 24 dBm)
alpha: It also impacts the calculation of PUSCH transmit power and also scales the contribution of path loss. Possible values are 0, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9 and 1
p0-NominalPUCCH: This parameter impacts the calculation of PUCCH transmit power (-127 to -96 dBm)
deltaFList-PUCCH: These parameters impacts the calculation of PUCCH  transmit power

deltaPreambleMsg3: It impacts the transmit power of PUSCH when responding to random access response grant (-1 to 6dB)

ul-CyclicPrefixLength:  To differentitate between normal (len1) OR extended (len2) cyclic prefix for uplink transmission

UE Timers and Constants

T300: Time during which UE waits for RRC connection request message response (100, 200, 300, 400, 600, 1000, 1500, 2000 ms)
T301: Started after RRC Connection Reestablishment request message. On expiration UE will go to RRC idle (100, 200, 300, 400, 600, 1000, 1500, 2000 ms)
T310: Started after receiving N310 out of sync indications (0, 50, 100, 200, 500, 1000, 2000 ms)
T311: Started after initiating connection re-establishment procedure. On expiration UE goes to RRC idle mode if it is unable to locate suitable cell (1, 3, 5, 10, 15, 20, 30 seconds)
N310: Consecutive out of sync indications (1, 2, 3, 4, 6, 8, 10, 20)
N311: Consecutive in-sync indications (1, 2, 3, 4, 6, 8, 10, 20)

Frequency Information

ul-CarrierFreq: Defined in terms of EARFCN
ul-Bandwidth: Defined in terms of resource blocks
additionalSpectrumEmission: This allows spectrum emission limits to be configured according to local requirements (1 to 32)

timeAlignmentTimerCommon: it tells UE how long it should consider itself to be time aligned in uplink in unit of subframes. (500, 750, 1280, 1920, 2560, 5120, 10240 or infinity subframes)



Quality of Service (QoS) in LTE

Background: Why we need QoS ? 

There are premium subscribers who always want to have better user experience on their 4G LTE device. These users are willing to pay more for high bandwidth and better network access on their devices. Not only the subscribers but some services itself need better priority handling in the network (e.g. VoIP call). To be able to full fill this, QOS plays the key role. QOS defines priorities for certain customers / services during the time of high congestion in the network

3GPP definition for QoS

In LTE Network QoS is implemented between UE and PDN Gateway and is applied to a set of bearers. 'Bearer' is basically a virtual concept and is a set of network configuration to provide special treatment to set of traffic e.g. VoIP packets are prioritized by network compared to web browser traffic.
In LTE, QoS is applied on Radio bearer, S1 bearer and S5/S8 bearer, collectively called as EPS bearer as shown in figure below.




In order to comprehend the concept of QoS , we must understand the bearer types and properties associated with each bearer through hierarchical chart as shown below. First there are two types of Bearer, i.e. Dedicated bearer and Default bearer. There is  at-least one default bearer established when UE is attached to LTE network while dedicated bearer is always established when there is need to provide QoS to specific service (like VoIP, video etc). Please go through the article Default and Dedicated Bearer which hopefully will help to explain the concept in more detail.



Dedicated bearer can be subdivided into Non-GBR and GBR types. 
GBR provides guaranteed bit rate and is associated with parameters like GBR and MBR
- GBR: The minimum guaranteed bit rate per EPS bearer. Specified independently for uplink and downlink
- MBR: The maximum guaranteed bit rate per EPS bearer. Specified independently for uplink and downlink

On the other hand, Non-GBR bearer does not provide guaranteed bit rate and has parameter like A- AMBR and UE- AMBR

- A-AMBR: APN Aggregate maximum bit rate is the maximum allowed total non-GBR throughput to specific APN. It is specified interdependently for uplink an downlink 
- UE -AMBR: UE Aggregate maximum bit rate is the maximum allowed total non-GBR throughput among all APN to a specific UE

As you can see, the default bearer can only be non-GBR type. Some other  important terms associated with each bearer type are discussed below:

- ARP: Allocation and retention priority is basically used for deciding whether new bearer modification or establishment request should be accepted considering the current resource situation.
- TFT: Traffic flow template is always associated with dedicated bearer and while default bearer may or may not have TFT. As mentioned earlier, dedicated bearer provides QoS to special service or application and TFT defines rules so that UE and Network knows which IP packet should be sent on particular dedicated bearer. It usually has rules on the basis of IP packet destination/source or protocol used.

L-EBI: It stands for Linked EPS bearer ID. As I discussed in previous article about dedicated and default bearer, we know that each dedicated bearer is always linked to one of default bearers. L-EBI tells Dedicated bearer which default bearer it is attached to. 

IP Address/ PDN: Each default bearer is attached to some PDN network and has its own IP address while dedicated bearer does not need this since it is linked to default bearer.

You can also see one other parameter associated with all bearers i.e. QoS class of identifier (QCI).This parameter basically defines IP level packets characteristics as shown below





EXAMPLE
Let me try to explain here again with the same example I gave in Default and Dedicated Bearer section

Usually LTE networks with VoLTE implementations have two default and one dedicated bearer

Default bearer 1: Used for signaling messages (sip signaling) related to IMS network. It uses qci 5
Dedicated bearer: Used for VoLTE VoIP traffic. It uses qci 1 and is linked to default bearer 1
Default bearer 2: Used for all other smartphone traffic (video, chat, email, browser etc), assuming qci 9 is used here



This means that Default bearer 1 is associated with IMS PDN and has specific IP address. It has throughput limitations defined in terms of A-AMBR and UE-AMBR. Since it has qci 5 which means that its IP packets has the highest priority over other IP packets and maximum delay as 100ms between UE and PGW with packet loss percentage up to 10-6

Default bearer 2 is associated with internet PDN and has specific IP. It has throughput limitations defined in terms of A-AMBR and UE-AMBR as well. Since it has qci 9 which means that its IP packets has the lowest priority over other IP packets and maximum delay possible as 300ms between UE and PGW with packet loss percentage up to 10-6

Dedicated bearer will be linked to Default bearer 1 with L-EBI and it also has TFT which basically defines which IP packets should be allowed to travel on this bearer. It has throughput limitations defined in terms of MBR and GBR. Since it is using QCI 1, the IP packets traveling on this bearer have the second highest priority. The maximum delay possible to IP packets on this bearer is 100 ms and the percentage of packet loss will be under 10-2