Quite a number of whitepapers on the LTE Radio Layer and about the general architecture of LTE can be found these days on the web. A good one for example is the Agilent LTE Air Interface Introduction, about which I have reported previously. What's still missing, however, is a good description of how resources are dynamically assigned in the uplink and downlink direction of the air interface. This process is also referred to as Radio Resource Control (RRC) and has a big impact on how well the available bandwidth can be shared between all active subscribers in the network. The following blog entry aims at shedding some light on this process.
The description below is based on the following documents, which are an ideal source for further background reading:
- Agilent's LTE Air Interface Introduction, especially figure 24 and 27
- 3GPP TS 36.300 850: E-UTRAN [i.e. LTE] overall description; stage 2
- 3GPP TS 36.321-820: E-UTRAN MAC protocol specification
- 3GPP TS 36.331-820: E-UTRAN Radio Resource Control (RRC) protocol specification
Idle State
Let's assume the mobile device is already registered and the network has assigned an IP address to it. Further, no data has been exchanged with the network for some time, so the mobile has been put into Idle state. In this state the radio part of the mobile is mostly dormant but periodically performs the following main tasks:
- Observes the paging channel in case the network needs to notify the device of incoming IP packets.
- Observes the broadcast channel of the current cell to be informed of configuration changes.
- Performs radio channel quality measurements on the current cell and neighboring cells. Neighboring cells can be other LTE cells but also UMTS, GSM and CDMA cells. For this purpose, the current cell broadcasts a list of neighboring cells. In case the radio coverage of the current cell becomes inferior to that of another cell, the mobile performs a cell reselection to a different cell.
Then let's assume the user starts the web browser on the mobile device and selects a web page from the bookmarks. This means that the mobile device has to request the establishment of a new radio bearer from the base station. It's important to note at this point that it's only the radio link that needs to be re-established, as an IP address is still assigned to the device.
The Random Access (TS 36.300, 10.1.5)
The first step in re-establishing radio contact is to initiate a Random Access Procedure on the (uplink) Random Access Channel (RACH). Where in the frequency/time resource grid the RACH is located is known to the mobile via the (downlink) Broadcast Channel (BCH). The random access message itself only consists of 6 bits and the main content is a random 5 bit identity.
If the network receives the message correctly it sends a Random Access Response Message at a time and location on the Physical Downlink Shared Channel (PDSCH) that can be calculated from the time and location the random access message was sent. This message contains the random identity sent by the device, a Cell Radio Network Temporary ID (C-RNTI) which will be used for all further bandwidth assignments, and an initial uplink bandwidth assignment.
The mobile device then uses the bandwidth assignment to send a short (around 80 bits) RRC Connection Request message which includes it's identity which has previously been assigned to it by the core network (or the Non Access Stratum (NAS) in 3GPP talk).This NAS id is required as the base station can only establish a radio bearer with information stored in the access gateway as described below.
Establishment of Radio Bearers
As the mobile device is already known in the core network the following radio bearers are now established automatically:
- A low priority signaling (message) bearer (SRB1)
- A high priority signaling (message) bearer (SRB2)
- A data radio bearer (DRB), i.e. a bearer for IP packets
Part of the bearer establishment procedure are authentication and activation of encryption. The required data for this process is retrieved by the base station (the eNodeB or eNB in 3GPP talk) from the Access Gateway (aGW), or more precisely from the Mobility Management Entity (MME). The MME also delivers all necessary information that is required to configure the data radio bearer, like for example min/max bandwidth, quality of service, etc.
Setting up a radio connection is a pretty extensive task. For the user, however, the delay caused by these procedures should be as little noticeable as possible. The LTE requirements say that the whole procedure should not take more than 100 milliseconds. It's likely that this can be achieved in practice, as the transmit time interval (TTI) of LTE is 1 millisecond, which means there are enough opportunities to exchange messaging in uplink and downlink within this period to complete the task.
Resource Scheduling
Once the DRB is in place, everything is set up and the mobile then listens on the Physical Downlink Control Channel (PDCCH) for uplink/downlink bandwidth assignments. The PDCCH is broadcast every millisecond (i.e. 1000 times a second) in the first 1-3 symbols out of 14 symbols which are transmitted every millisecond. Figure 24 in the Agilent document visualizes this very nicely.
In downlink direction, resources are scheduled for the device on the PDCCH whenever data arrives from the network. How many Physical Downlink Shared Channel (PDSCH) ressources are scheduled and when mainly depends on the quality of service settings for the user and the current radio conditions.
In uplink direction, the mobile is only allowed to send data on the Physical Uplink Shared Channel (PUSCH) when the network schedules uplink transmission opportunities on the PDCCH. Uplink and downlink bandwidth assignments on the PDCCH are encapsulated in so called Control Channel Elements (CCE's, in case you come across this acronym in the specification documents), which are fixed length containers to simplify the search for the mobile on the PDCCH for its own bandwidth assignments)
Uplink resources are scheduled based on the amount of data in the uplink buffer of the mobile. The mobile device can signal the amount of data waiting to be transmitted in a the MAC header part of uplink packets. QoS and other parameters are of course also used by the base station in the uplink scheduling decision.
HARQ
As transmissions over the air interface are prone to transmission errors due to interference, each packet sent in uplink and downlink direction has to be acknowledged by the other end. This is done by sending Hybrid Automatic Repeat Request (HARQ) acknowledgments or non-acknowledgments on control channels.
In downlink direction, HARQ acks/nacks are for uplink transmissions are sent on the Physical HARQ Indicator Channel (PHICH), which is part of the PDCCH, i.e. they are transmitted in the first 1-3 symbols of each TTI. In uplink direction, HARQ ACK/NACKs are sent on the Physical Uplink Control Channel (PUCCH), which is implicitly scheduled shortly after a downlink transmission. Figure 27 in the Agilent document shows the PUCCH in orange.
CQI and Neighboring Cell Measurements
To be able to optimize downlink transmissions by adapting the modulation and coding scheme (MCS), the mobile device has to send channel quality indications (CQI) on the PUCCH and the PUSCH). In addition, the mobile also collects measurements on neighboring cells and reports them to the base station whenever a threshold is crossed (e.g. a neighboring cell is received better than the current cell).
DRX
With all of this work going on besides sending and receiving data, a discontinuous reception (DRX) mechanism has been designed so the mobile can switch off its transmitter periodically to conserve battery power. The activity and switch-off time can be set by the base station based on the QoS of the connection and current activity of the device. It's interesting to note at this point that the DRX cycle can range from a few milliseconds up to several seconds. More precisely the DRX cycle can be as long as the paging cycle while the mobile does not have a radio bearer.
Many more details could be added, but I think this description covers the basic procedures for exchanging data of the LTE air interface. Hope you liked it.