PDCCH Order in LTE

PDCCH Order is a procedure to bring back uplink out-of-sync UE (user equipment) back to in-sync state incase there is downlink data available for it. This can happen in situation when the time alignment Timer  gets expired because there is no uplink and dowlink data transmission for some time and also when there is no Time alignment command recieved from eNB. Time Alignment timer basically controls how long the UE  is considered uplink time aligned.

For viewers to better understand PDCCH Order, here is an example :


    1. Lets assume we have a UE that is in RRC connected state
    2. There is uplink / downlink user data being transmitted for some time (like facebook activity etc)
    3. There is no more data to be transmitted. Time Alignment timer will start (expiry setting = 10 seconds). But remember the RRC Inactivity Timer will also start since there is no data activity but lets assume that our Inactivity Timer doesnt expire and we remain in RRC connected state for whole duration
    4. Time Alignment timer expires and UE is considered uplink out-of-sync now. At this point UE releases all PUCCH (scheduling resources, CQI configuration) and SRS resources. UE also flushes its HARQ buffers
    5. UE is still in RRC Connected state but it has no PUCCH/SRS resources as they were released previously. Now there is DL data in eNB buffer for UE (Like facebook notification or something) but first UE has to be brought back to in-sync state and also it needs to reconfigured again with PUCCH/SRS resources
    6. eNB sends PDCCH order to UE using DCI 1A format. This is basically signal to UE to perform the contention less RACH with preamble index already included in DCI 1A 
    7. UE sends MSG1 using RACH preamble acquired from PDCCH order (To read more about RACH procedure in LTE, click here)
    8. eNB sends RACH response with new time advance value so that UE can be uplink in-sync
    9. UE is in sync again ! 
    10. Next eNB sends RrcConnectionReconfiguration message which carries PUCCH/SRS as they were released when the time alignment timer was expired at step 4
    11. UE confirms reception of RrcConnectionReconfiguration message and now can resume uplink/downlink transmission of data

    Why UE needs time alignment ? 
    Due to different signal transmission paths and movement, UE can lose time synchronization to eNB subframe. eNB measures the time alignment of UE by measuring the difference between arrival time of PUCCH, PUSCH, SRS  to its own uplink subframe

                      How to build your own LTE Quadcopter

                      Having a quadcopter being controlled through LTE network without any limit in its flying range ( with an exception of battery backup and LTE coverage limit of course ) had always been a very appealing and interesting notion. There are few solutions available which are costly, So I wanted to come up with a cheaper alternative

                      First, lets begin with the main parts that will be needed to build on your LTE controlled Quadcopter.
                      See the required parts below

                      - Raspberry Pi (Amazon Link)   price ~$40
                      - F450 Quadcopter Kit (Ebay Link)  price ~$80
                      - LTE Dongle (Amazon Link)  price ~$50
                      - Battery Pack (Lipo) (Ebay Link) price ~$18
                      - Lipo Charger (Ebay Link) price ~$25
                      - Flight Controller CC3D (Ebay Link) price ~$13
                      - PC Gaming Joystick (Amazon Link) price ~$29

                      Some Background

                      A Quadcopter consists of four arms with a motor and propeller on the end of each arm. Two propellers are turning clockwise and the other two are turning counter-clockwise. There is a flight controller which keeps it leveled and converts your input commands into motion which it needs to fly. There are many cheap flight controllers available in the market. The one I used is called Open Flight CC3D. It costs only $13. Some other popular alternatives are

                      - Hobbyking KK2.1.5 Flight controller
                      - APM2.6 Ardupilot Flight Controller
                      - Naze32

                      Main parts of Quadcopter consists of a frame, a receiver, a flight controller, electronic speed controls, motors, and propellers. See below  for complete picture

                      Quadcopter Operation


                      Quadcopter motion (Throttle, Yaw, Pitch, Roll) commands are sent via RC Transmitter to RC Receiver and are  converted to PWM signals which are then used by flight controller to control the speed of Motors via Electronic Speed Conrollers (ESC). Most modern transmitters use a 2.4 Ghz frequency. RC receivers come mostly with 6 channels receivers.  Channels are the amount of things you can control. For example a four channel transmitter means you can only control four motors/servos/accessories. Mostly RC transmitter has 6 channels. These channels are controlling the Throttle, Yaw, Pitch, Roll, Aux 1, and Aux 2 (Aux can be used for different feature on your Quadcopter)

                      The output of the receiver is in the form  PWM signals. PWM stands for Pulse Width Modulation. PWM is a technique used to transmit data in the form of a varying pulse width. In the case of R/C electronics this time is usually 1-2 milliseconds.  For example, full throttle on your transmitter will send a 2 ms pulse to flight controller while zero throttle means puls of width 2 ms. Same rule applies to other controls on your transmitter. PWM pulse frequency is 20ms. The image below represents a typical PWM frame

                      PWM Signal output from RC Receiver

                      Replacing UHF Radio Link with IP Communication 

                      Main objective here is to replace the UHF radio link (2.4 Ghz) with IP communication network. Instead of using RC Transmitter we will use a regular PC gaming joystick to send control commands to Quadcopter through IP network. The commands are received by LTE dongle connected to Raspberry pi computer which converts these commands to PWM signals. The PWM signals are then used by CC3D flight controller to control the motion of flight.  See the below figure for end to end communication path

                      LTE Quadcopter

                      Note: If you are not familiar with raspberry pi, please visit https://www.raspberrypi.org/ to get some understanding .To put it short, It is is wonderful cheap little computer that can be used to make home media center, VPN, make robot and many more interesting projects. You can use almost any language on RPi though I always prefer to use Python as being very easy , high level and dynamic programming language

                      Raspberry Pi 2

                      Installing LTE modem on Raspberry Pi

                      I used Sakis3g script to install the drivers and application to configure the LTE modem. You can find more information at http://www.sakis3g.com/

                      How to communicate with LTE Dongle Private IP

                      One of the issue with LTE modem (dongle) is that it will be assigned private IP and will use Network Address Translation (NAT) to communicate to external world. NAT is the process where firewall assigns a public address to a network device inside private network. NAT save on the IP addresses as every network device (LTE dongle in our case) does not need a public address, and also it would hide these private devices from the outside world. For our quadcopter LTE dongle, it means that we wont be able to use the IP which is assigned to it in order to establish any IP communication to it. To overcome this problem we have to use our home Wifi router's port forwarding feature (application of NAT). Since our router's public IP is known to us ,therefore forwarding packet to our home PC coming from LTE quadcopter will not be an issue.

                      Let's assume that LTE dongle is assigned private IP 10.10.10.50 by the LTE network, Let's  also assume our home computer has private of 192.168.10.44 which was assigned by the Wifi router. Secondly our Wifi router has public IP of 173.75.180.60 which is known to us. We use TCP port 50050 for any communication from LTE quadcopter to Home PC. Now all we have to do is defining port forwarding table in our home wifi router. The basic rule that needs to be defined is to forward all incoming TCP packet with destination port of 50050 to our controller PC which has IP 192.168.10.44 and you are all set to have IP communication between Quadcopter and our home PC



                      Now here is how our end to end Communication will work

                      - Using Python's socket module function, Raspberry Pi (with LTE modem connected) will open a TCP connection to a port 50050 and IP 173.75.180.60.

                      - Python Socket Module on our home pc waits until a client connects to the port you specified

                      - Our home router forwards all incoming TCP packet with destination port of 50050 to our controller PC which has IP 192.168.10.44

                      - Once a socket is open, you can read from it like any IO object.

                      Below is the very basic python code that I used to do the communication between Raspberry Pi and home Computer as explained above. The code is just to give you a starting point while you can optimize the code below to have much better stabilized flight :)

                      Python Code on PC side




                      Python Code on Raspberry Pi side




                      Video Streaming from Quadcopter to Home Wifi Network 

                      Currently I am having trouble transmitting video from Quadcopter to Home Computer. I used  netcat utility to do the streaming but it makes  RPi reset every time. I believe I need to provide separate power bank. I will give update on it once successful, hopefully soon.


                      LTE Physical Uplink Control Channel (PUCCH)

                      Physical Uplink Control Channel (PUCCH) carries Uplink Control Information (UCI) which is basically bits and pieces of information that eNB requires from UE in order to understand what UE (user equipment) needs and carries other information like channel quality that UE is seeing in downlink,  etc

                      UCI is divided into three main sub branches i.e. Channel State Information (CSI), Scheduling Requests (SR) and HARQ ACK/NACK shown with some details as below



                      Note: 3GPP Release 8 and Release 9 UEs cannot transmit PUCCH and PUSCH on same TTI. If UE has to transmit UCI and data simultaneously within the same TTI, then PUSCH is used for UCI transmission but Release 10 allows simultaneous transmission of PUSCH and PUCCH

                      3GPP has defined different PUCCH formats to transfer different combinations of the information as can be seen in below table


                      A single PUCCH transmission always occupies 2 Resource Blocks
                      Frequency diversity of those two RBs is ensured by slot based PUCCH frequency hopping (See figure below) Each pair of RBs allocated to PUCCH can be used simultaneously by multiple UEs by
                      using different cyclic shifts and different orthogonal spreading codes



                      PUCCH Capacity Calculations

                      Remember every  RRC Connected UE needs to send CQI reports periodically!

                      Basic formula to calculate how many UEs (RRC Connected) are supported by eNB is

                      Number of UEs = Number Resource blocks used for CQI reporting x UEs Multiplexed per Resource Blocks x CQI reporting periodicity

                      The CQI reporting periodicity (in subframes) are determined based on the parameter
                      cqi-pmi-ConfigIndex given in Table 7.2.2-1A for FDD in 3GPP TS 36.213

                      Example
                      Lets assume we have reserved  5 resource blocks (eNB Parameter) for CQI reporting and 6 UEs can be multiplexed per resource blocks. Also lets assume that CQI periodicity is 40 ms then the total number of RRC Connected UEs that eNB can support is as below

                      Number of UEs= 5 * 6 * 40 = 1200



                      Note: This is not the only limitation for how many RRC Connected users eNB can support. The above capacity calculation is just to explain the requirement atleast from UE CSI reporting perspective