S1 – Control/User Plane

On the S1 reference point the physical layer L1 will in most cases be realized by Gigabit Ethernet cables. L2 in this case will be Ethernet. On top of Ethernet we find IP, but used as a transport protocol between two network nodes: eNB and MME. This lower layer IP does not represent the user plane frames.

Instead, the user plane IP frames (higher layer IP) are carried by the GTP Tunneling Packet Data Unit (T-PDU). The GTP is responsible for the transport of payload frames through the IP tunnels on S1-U. The transport layer for GTP-U is the User Datagram Protocol (UDP). As IP this protocol may be found twice in the user plane stack: lower UDP for transport between the eNB and MME and higher UDP (not shown in Figure 1) that is transparently routed through the mobile network as the transport protocol for real-time application data. The higher layer IP on top of GTP-U as well as all application data on top of this higher layer IP are identical with the user plane information.

 
Figure 1: Protocol stack S1 control/user plane

On the control plane side, the Streaming Control Transport Protocol (SCTP) provides reliable transport functionality for the very important signaling messages. S1AP is the communication expression between MME and S-GW while NAS

LTE Network Protocol Architecture

Uu – Control/User Plane

The protocol stack used on radio interface Uu is shown in Figure 1. The physical layer in this stack is represented by OFDM in the DL and SC-FDMA in the UL. Then we see the MAC protocol that is responsible for mapping the transport channels onto the physical channels, but also for such important tasks as packet scheduling and timing advance control. RLC provides reliable transport services and can be used to segment/reassemble large frames. The main purpose of PDCP is the compression of larger IP headers as well as ciphering of user plane data and integrity protection of both user plane and control plane data.

 
Figure 1: Protocol stack LTE Uu interface

On top of PDCP the stack is split into the user plane and control plane parts. On the control plane side we see RRC protocol, that is, the expression for the communication between the UE and eNB. RRC provides all the necessary functions to set up, maintain, and release a radio connection for a particular subscriber. 

RRC also serves as a transport protocol for NAS signaling messages. NAS is the expression for the communication between the UE and MME in which MME represents the core network.

On the user plane side we see IP as the transport layer for end-to-end applications. On the Uu stack the IP is always end-to-end IP, which means that all these IP packets are transparently routed, often tunneled through the mobile network. The user plane IP frames we see on Uu are the same IP frames that can be monitored at SGi reference points before or behind the PDN-GW.

The IP version can be Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6). In the case of VPN (Virtual Private Network) traffic, IPsec will be used.

The applications on top of IP in the user plane stack are all protocols of the TCP/IP suite, such as the File Transfer Protocol (FTP), HTTP (web-browsing), and POP3/SMTP (for e-mail), but also Real-Time Transport Protocol (RTP) and SIP for real-time services like VoIP.

Transport Channels in LTE

The physical layer provides a transport service for MAC PDUs. This service is accessed by transport channels. Most transport channels are directly mapped to physical channels. Thus, in other words, transport channels are the gateway to physical channels and a selection for MAC PDUs where they are to be transmitted.

The following DL transport channel types are defined:

• Broadcast Channel (BCH):
  • – Uses a static transport format and has the requirement that all UEs within the cell have to receive its information error-free. The reception of the BCH is mandatory for accessing any service of a cell.
• DL-SCH:
  • – Carries all semi-static broadcast information (SIB) and all UE-specific traffic channels.
  • – DL-SCH is secured with HARQ algorithms.
  • – Efficiency is realized with AMC link adaptation.
  • – Various TMs are defined to meet different environment scenarios to increase efficiency in respect of current conditions.
  • – DRX is available in order to increase handset operating time.
  • – Makes use of spatial algorithms like beamforming or MIMO.
• Paging Channel (PCH):
  • – Needs to be received in complete cell coverage area.
  • – Supports DRX in order to increase battery operating cycle.
  • – Dynamically allocated via own physical identifier (P-RNTI).
• Multicast Channel (MCH):
  • – Broadcast to entire cell coverage area.
  • – MBMS transmission with use of multiple cells.

A designated DL control channel is not defined as the PDCCH is used for physical channel control only. All the higher layer control plane is transmitted via the DL-SCH.

Defined UL transport channel types are shown in the following items:

• UL-SCH:
  • – UL-SCH is secured with HARQ algorithms.
  • – Fully dynamic and semi-static resource allocation schemes.
  • – Can make use of multi-user MIMO (UL "virtual" MIMO).
  • – Uses dynamic link adaptation like AMC.
• RACH:
  • – Accessible without UL synchronization.
  • – Collision-based and collision-free operating modes.
  • – Various modes depending on cell size and interference.

As in the DL direction, no UL control transport channel is defined as all the higher layer control plane is transmitted on the UL-SCH. The PUCCH is a control channel used by the physical layer only.

Link Adaptation in LTE

Mobile wireless reception conditions vary greatly over frequency and time as described in Section 1.8. In order to cope with these circumstances and guarantee best possible QoS, a procedure is implemented known as Adaptive Modulation and Coding (AMC). AMC controls and changes transmission parameters to achieve a defined Transport Block Error Rate (BLER) of below 10%, in order to keep retransmissions in a suitable range. This is done by adapting the modulation scheme, in LTE on the shared channels between QPSK and 64QAM, and the Forward Error Correction (FEC) coding rate.

Different modulation schemes make the bit detection more robust against noise and other distortion caused by the wireless channel. Figure 1 shows the applied modulation scheme for the LTE shared channels. Most robust transmission is achieved by mapping just 2 bits to each modulation symbol as seen with QPSK, resulting in four stages. A large distance between modulation points as seen with QPSK allows a higher probability of the correct decision at the receiver even with noisy reception conditions. Both 16QAM and 64QAM map 4 and 6 bits respectively to one modulation symbol used with better wireless channel conditions to achieve a higher data throughput. It is to find the best compromise between the modulation scheme and code rate for a given channel quality. LTE defines a list of MCS combinations and just signals an MCS index.

 
Figure 1: Different QAM schemes used with LTE and the number of bits mapped to each scheme

The data modulated with the different modulation schemes to subcarriers needs to be protected against transmission errors. LTE defines a turbo de-/encoder with trellis termination of a native code rate of one-third. The turbo coder adds redundancy bits to the data, which makes it possible to correct some bit errors. The code rate is a fraction of source data rate to resulting protected data rate; thus, a code rate of one-third encodes 1 bit into 3 bits. Other code rates are needed in order to optimize the trade-off between protection and efficiency. This is done by puncturing the native coded bit stream to a higher (less protection) code rate by deterministically leaving out coded bits, or by deterministically repeating coded bits if a smaller code rate is desired (more protection).

Additionally, one parameter being controlled is the UL transmit power. UL power control is implemented to deal with the near–far effect. Figure 2 shows an UL scenario with a near–far effect compared to a DL scenario without power differences between user signals as they are equally attenuated because the mix of the signal is transmitted from one position (eNB). This occurs when a user is close to the base station (near) and another user is far away from the base station, introducing a higher power path loss which leads to a lower receive power of the signal of the cell edge user. All UL receive signals should have equal power in order to have the same analog-to-digital converter saturation of each signal to reduce the quantization noise of users with low received signals, reducing inter-subcarrier interference between the users. This happens with imperfect UL synchronization within real-life scenarios.

 
Figure 2: Near–far effect occurring in uplink direction, compared to equal signal strength reception in downlink

UL TPC commands are sent via designated DCI formats 3 and 3A. DCI 3 and 3A are differential power control commands for PUCCH and PUSCH transmission in steps of decibels. DCI 3 is a 2bit assignment as opposed to DCI 3A which is a single bit command. These dedicated DCIs with TPC commands are only used when there is no data to be transmitted to the UE; otherwise, the TPC command is transmitted embedded in other control information on the PDCCH for this UE. An initial 3-bit TPC command is embedded in the RAR message. The different TPC commands are listed in Tables 1 and 2.

Table 1: Mapping of TPC command field in DCI format 1A/1B/1D/1/2A/2/3 to δ_PUCCH values. Reproduced with permission from © 3GPP^™ 

TPC command field in DCI format 1A/1B/1D/1/2A/2/3	δPUCCH (dB)
0	-1
1	0
2	0
3	3

Table 2: Mapping of TPC command field in DCI format 3A to δ_PUCCH values. Reproduced with permission from © 3GPP^™ 

TPC command field in DCI format 3A	OPUCCH (dB)
0	-1
1	1

UEs report their received channel quality to the eNB by transmitting a CQI value. The CQI value represents either a wideband receive quality as a scalar or a more detailed report about frequency sections (sub-bands) as a vector. CQI reports are transmitted periodically or aperiodically configured by higher layers. Sub-band CQI reports indicate the receive quality of each sub-band relative to the wideband average with four steps: worse, equal, better, and much better. The UE reports the best M sub-bands compared to the average channel quality with the best M method as depicted in Figure 3.

 
Figure 3: CQI illustration with sub-bands and best M reporting. Reproduced with permission from Nomor

The UE should derive a MCS scheme from the above measurement information, which is indexing 1 MCS out of 16 to suit the target BLER of below 10%. This enables differentiation between high- and low-cost handsets which use more or less expensive RF hardware and/or a more sophisticated IQ signal processing engine.

Recapitulating, LTE link adaptation uses various stacked link adaptation techniques, securing transmission, or in order to make it more effective using different control loop delays regarding the process's dimension. The following items summarize the LTE link adaptation functions with their responsiveness:

Adaptive frequency-selective scheduling: Assign frequency resource to UEs on a 1 ms basis, which provides each UE with the individual best reception quality. AMC: Obtain the most efficient modulation and FEC code rate in order to balance retransmissions vs. maximization of throughput. HARQ: Multiple retransmission process using prior transmission to increase the correct decoding probability. TPC: Provides UL power control in order to minimize multiple user interference.

Scheduling on LTE Upload

The LTE UL scheduling is very similar to the DL scheduling, although the UL scheduler is a distinct entity. This section describes the difference from the DL scheduling only.

UL scheduling grants are indicated to the UE by transmitting all relevant UL scheduling information within the PDCCH. This is done by using a dedicated DCI type, DCI 0. Each UE has to monitor the PDCCH in every subframe for DCI types 0 scrambled with their RNTI. This does not apply for the case when power saving mode DRX is enabled, which switches off the UE's receiver periodically. UL resources are allocated without a designated PDCCH UL grant in the case of SPS or for non-adaptive HARQ retransmissions. A non-adaptive HARQ retransmission is triggered by the transmission of a Negative Acknowledgment (NACK) by the UE.

 
Figure 1: Example PDCCH message of DCI format 0 (uplink scheduling grant)

In the UL only localized scheduling is allowed, which means that an integer number of consecutive RBs is allocated to one UE. Furthermore, there is only one scheduling process per UE, thus there is not a dedicated scheduling process per radio bearer.

The UE feeds the UL scheduler with CQI, Buffer Status Reports (BSRs), ACKs/NACKs, and Scheduling Requests (SRs). BSRs indicate the fill level status of the current transmit buffer. This buffer status is reported in bins, quantizing the fill level in bytes. Figure 2 shows an example of a MAC BSR message.

 
Figure 2: Example MAC Buffer Status Report (BSR) message

LTE trial studies show that there are various cases of scheduled empty UL grants. This happens when the eNB assigns UL resources to a UE and the designated UE does not use those UL resources for an UL transmission. Operators should minimize such empty scheduled UL resource in order to optimize the usage of UL radio resources.

OFDM Scheduling on LTE DL

The eNB advises each UE when and on which resources to transmit its data or informs a UE where it should listen to receive data. The resources are defined by frequency and time units. This procedure of assigning system resource is called scheduling. The system resources are divided into units of RBs. Only integer numbers of RBs can be assigned to one user. Localized and distributed RB allocations are possible. Localized allocations assign adjacent RBs to one UE, distributed allocations distribute the scheduled RBs over the spectrum with gaps, for example, in order to achieve frequency diversity.

A new scheduling assignment is transmitted for each subframe, thus the scheduling period on the time axis is 1 ms. The DL scheduling information is transmitted in the PDCCH. The assignments on the frequency scale vary between one RB (minimal scheduled transmission) and the maximum number of available RBs in respect of the system bandwidth.

Generally, the LTE scheduling algorithm is not defined by the standard; it is a matter for the eNB vendors. This enables the base station vendors to differentiate between each other and use different optimization goals. Various parameters can be used as input for the scheduling decisions: channel quality of different users (measured or reported by the UE with the Channel Quality Indicator, CQI), QoS, congestion/resource situation, fairness, charging policies, and so on. Most schedulers aim to maximize the cell throughput under consideration of fairness metrics between cell edge users and users with very good channel conditions. Figure 1 shows a screenshot of a typical scheduling and cell resource allocation analysis tool. It gives insight into the scheduling process of the eNB and is able to evaluate the scheduler performance and the utilization of cell resources.

 
Figure 1: Scheduling and cell resource allocation analysis

The CQI is reported in the UL direction and can be derived periodically or upon request by the eNB. It gives reception quality feedback to the scheduling algorithm in the eNB in order to schedule data on those frequency regions with the best possible reception characteristics. 

The scheduling information is encoded as Downlink Control Information (DCI). The DCI is then mapped to REGs of the PDCCH. The length of the PDCCH can vary between one and three OFDM symbols depending on the load to be transmitted on the PDCCH. The number of used OFDM symbols is indicated in the PCFICH.

The DCI does not just transmit RB assignments and its assignment type, but also other information needed for the transmission or reception of data. This information is, for example, the Modulation and Coding Scheme (MCS), HARQ feedback information, or power control commands for UL transmission of the Physical Uplink Control Channel (PUCCH) or Physical Uplink Shared Channel (PUSCH) (see below).

The following DCI formats are defined and used for scheduling and UL Transmit Power Control (TPC) commands:

• DCI format 0: UL scheduling grant.
• DCI format 1: Single transport block (code word) scheduling assignment, for example, used for assigning resources to system information, paging, or random access. Further information: MCS, HARQ (New Data Indicator (NDI), redundancy version, HARQ process number), and TPC for PUCCH.
• DCI format 1A: Compact single transport block scheduling assignment. Further information: MCS, HARQ (NDI, redundancy version, HARQ process number), and TPC for PUCCH.
• DCI format 1B: A special DCI format for transmission mode 6 (MIMO closed loop rank 1 pre-coding). Further information: precoding vector, MCS, HARQ (NDI, redundancy version, HARQ process number), and TPC for PUCCH.
• DCI format 1C: Even more compact scheduling format as DCI 1A. For example, used for assigning resources to SIBs, paging, or RARs. This DCI is always transmitted using frequency diversity via distributed virtual resource block assignments using resource allocation type 2 (see below). This is done because channel feedback cannot be derived for such common information, as it is received by multiple users. The modulation is fixed to QPSK. Further information: MCS, HARQ (NDI, redundancy version, HARQ process number), and TPC for PUCCH.
• DCI format 1D: A special DCI format for transmission mode 5 (multi-user MIMO). Further information: MCS, HARQ (NDI, redundancy version, HARQ process number), power offset indicator if two UEs share power resources, and TPC for PUCCH.
• DCI format 2: Scheduling for transmission mode 4 (closed loop MIMO), multiple antenna port transmission operation, addressing multiple transport blocks (code words) to be transmitted on different antenna ports (layers). Further information: MCS for each transport block, HARQ (NDI, redundancy version, HARQ process number), number of transmission layers, precoding, and TPC for PUCCH.
• DCI format 2A: Used with transmission mode 3 (open loop MIMO using Cyclic Delay Diversity (CDD)), multiple antenna port transmission operation, addressing multiple transport blocks (code words) to be transmitted on different antenna ports (layers). Further information: MCS for each transport block, HARQ (NDI, redundancy version, HARQ process number), number of transmission layers, precoding, and TPC for PUCCH.
• DCI format 3: A 2-bit UL TPC command applying for PUSCH and PUCCH. Multiple users are addressed.
• DCI format 3A: A 1-bit UL TPC command applying for PUSCH and PUCCH. Multiple users are addressed.

The resource allocation assignments of the above DCI formats can use different resource allocation types. Table 1 maps the DCI formats to the allowed resource allocation types:

• Resource allocation type 0: With resource allocation type 0 a bit map is transmitted describing Resource Block Groups (RBGs). A RBG is a number of consecutive physical resource blocks (RBs). The number depends on the system bandwidth and has a range between one and four physical RBs. Table 1 maps the size of a RBG to the system bandwidth. The allocated RBGs do not have to be adjacent.

  Table 1: Resource allocation types and the applying DCI formats TS36.213. Reproduced with permission from © 3GPP^™ 

  Resource allocation type	Applying DCI formats
  Type 0	1, 2, 2A, and 2B
  Type 1	1, 2, 2A, and 2B
  Type 2	1A, 1B, 1C, and 1D

  Table 2: Type 0 resource allocation RBG size vs. DL system bandwidth 

  System bandwidth NRD BL	RBG size (P)
  ≤10	1
  11–26	2
  27–63	3
  64–110	4

• Resource allocation type 1: The bit map transmitted with resource allocation type 1 makes use also of RBGs but can address single physical RBs by introducing additional flags. The number of RBGs is smaller than the ones used with resource allocation type 0, thus not reaching the complete bandwidth. The bit map addresses not whole RBGs, but a subset within each RBG which is pointed to by the bit map. A selection flag indicates the position within the RBG regions and a shift flag shows the position of the numbered RBGs within the system bandwidth as the number of RBGs does not address the complete system bandwidth: shift flag = 0 indicates that the RBGs start at the beginning of the system bandwidth leaving an unaddressable region at the end of the system bandwidth; shift flag = 1 indicates that the RBGs are shifted to the end of the system bandwidth leaving the unaddressable region at the beginning of the system bandwidth.
• Resource allocation type 2: This resource allocation type uses virtual RBs as scheduling units. Two types of virtual RB scheduling assignments are used:
  • – A localized type, where the allocated virtual RBs equal a number of consecutive physical RBs addressed with a starting RB and a number of adjacently assigned RBs. This information is encoded into an 11-bit Resource Indication Value (RIV).
  • – A distributed type, where the addressed virtual RBs are distributed over the frequency with one or two gaps (depending on the system bandwidth) hopping at slot boundaries. Virtually distributed RB assignments are always used with DCI format 1C. There is a 1-bit flag indicating whether virtual distributed or virtual localized RB assignment is used in the case of DCI formats 1A, 1B, and 1D.

Instead of addressing a UE with a PDCCH scheduling assignment (DCI) directly by adding a UE ID (e.g., a RNTI) to the DCI, the 16-bit CRC of the PDCCH message is scrambled with the RNTI, introducing common and UE-specific search spaces. This CRC scrambling saves additional resources in DCIs, but increases slightly the chance of decoding a DCI for a different UE which is not intended to be addressed.

Figure 2 depicts an example PDCCH message of DCI format type 1 with all the transmitted information.

 
Figure 2: Example PDCCH message of DCI format 1 (downlink scheduling assignment)

Some special applications require the transmission of small data chunks in equidistant periods of time. An example is a VoIP application. In order to minimize the signaling overhead in such cases, a mode Semi Persistent Scheduling (SRS) is introduced. SPS parameters are configured by the RRC layer, enabling the transmission of data on defined RBs in frequency and time without further scheduling on the PDCCH.

Battery energy saving is always an important topic with mobile handset systems. A potential scheduling assignment could be sent in each PDCCH which occurs every millisecond. Therefore, each attached UE would need to monitor the PDCCH each millisecond for scheduling information. The DRX mode enables the UE just to listen to defined subframes for scheduling assignments and turn off its receiver in between, in order to save battery consumption. Short and long DRX cycle periods are defined. The DRX parameters are set by MAC and RRC. Figure 3 depicts a DRX cycle.

 
Figure 3: DRX cycle.

LTE Security | Standards, Protocols, and Functions

What are the new security functions in the E-UTRAN? This question can briefly be answered as follows.

The first feature we see is a completely new ciphering mechanism and integrity protection for NAS signaling messages that was never seen in any 2G or 3G radio access network. On the radio interface this new NAS security leads to situations with double ciphering. On top of the protocol stack the NAS messages exchanged between the UE and MME are encrypted and the underlying RRC that acts as the transport layer for NAS is secured by ciphering mechanisms as well, so that the ciphered NAS message is ciphered together with its RRC transport message a second time.

The second new security feature is the option to secure the complete IP-based transport of the control plane and user plane on the S1 reference point using Secure IP (IPsec). There is no way to decipher IPsec by just monitoring the data that is exchanged between two endpoints of an IPsec connection. To decipher IPsec requires the monitoring software to be informed about which IPsec ciphering parameters (which can be changed frequently) are currently used in each of the involved endpoints of the IP connection. In a typical case these endpoints are the eNB and the MME or S-GW. To allow deciphering, there must be a dedicated Application Programming Interface (API) installed that allows the monitoring software to access IPsec-relevant parameters for deciphering. To design such an API requires close cooperation between the NEMs of eNB and MME/S-GW and the manufacturers of the monitoring software. The conclusion related to this fact is that free-of-charge monitoring software like WireShark will not be able to decipher IPsec. However, to obtain statistics of S1 control plane and user plane performance it is crucial to have metrics for E-UTRAN QoS and QoE (Quality of Experience). Consequently, IPsec deciphering will become one of the key differentiators for E-UTRAN monitoring software.

Besides these new security features, all the security elements from previous standards such as mutual authentication and masking of subscriber identity by using temporary identities can be found in the E-UTRAN. There is only a minor change here: the TMSI will be replaced by the new GUTI parameter.

To understand how the overall LTE security concept works, it is crucial to understand the hierarchy of LTE security keys first. This LTE security key hierarchy, shown in Figure 1, includes the following keys: K_eNB, K_NASint, K_NASenc, K_UPenc, K_RRCint, and K_RRCenc:

• K_eNB is a key derived by the UE and MME from K_ASME or by the UE and target eNB from Ke_NB* during eNB handover. K_eNB should only be used for the derivation of keys for RRC traffic and the derivation of keys for UP (User Plane) traffic, or to derive a transition key K_eNB* during an eNB handover.
  
  

Figure 1: LTE security key hierarchy (according to 3GPP 33.401). Reproduced with permission from © 3GPP™

Keys for NAS traffic:

• KNASint is a key which should only be used for the protection of NAS traffic with a particular integrity algorithm. This key is derived by the UE and MME from Kasme, as well as an identifier for the integrity algorithm.
• KNASenc is a key which should only be used for the protection of NAS traffic with a particular encryption algorithm. This key is derived by the UE and MME from Kasme, as well as an identifier for the encryption algorithm.

Keys for UP traffic:

• K_UPenc is a key which should only be used for the protection of UP traffic with a particular encryption algorithm. This key is derived by the UE and eNB from K_eNB, as well as an identifier for the encryption algorithm.

Keys for RRC traffic:

• K_RRCint is a key which should only be used for the protection of RRC traffic with a particular integrity algorithm. K_RRCint is derived by the UE and eNB from K_eNB, as well as an identifier for the integrity algorithm.
• K_RRCenc is a key which should only be used for the protection of RRC traffic with a particular encryption algorithm. K_RRCenc is derived by the UE and eNB from K_eNB as well as an identifier for the encryption algorithm.

Now, whenever a call is established the security functions will work as shown in Figures 2–4. The start trigger of the security functions is when an initial NAS signaling message sent by the UE that contains UE security capability information arrives at the MME. The security capability list informs the MME for instance about which ciphering and integrity protection algorithms are supported by this UE.

Figure 2: Subscriber authentication

Figure 3: NAS security initiation and RRC security initiation

Figure 4: RRC security completion

After the MME has received the initial NAS message and it has not been in contact with this subscriber before, or if all previously received security tokens sent by the HSS have been used, the MME must contact the HSS to receive new tokens. Thus, the MME sends a DIAMETER authentication information request message to the HSS that contains the subscriber's identity. The HSS holds the secret network key "K" that is also stored on the USIM card of each subscriber. "K" is unique to every network operator.

From "K" and the subscriber's identity the HSS derives three of the four parameters found inside the DIAMETER authentication information response message: the security key K_ASME, the Authentication Token (AUTN), and the Expected Response (XRES) parameter. The random number parameter RAND is truly just a random number.

After the MME has received these four parameters, it produces three more derivatives from K_ASME. These derivatives are the NAS encryption key K_NASenc, the NAS integrity protection key K_NASint, and the security key for the eNB K_eNB.

What follows is the authentication procedure between the MME and the UE. The MME sends the unciphered NAS authentication request message that includes the random number RAND and the AUTN. Now the UE must use its secret key "K" from the USIM card to calculate another number based on "K," AUTN, and RAND. The number is the UE's authentication response number RES.

RES is sent back to the MME by using the authentication response message, and in the last step of the authentication procedure the MME compares the value of RES to the value of XRES, which is the XRES value computed previously by the HSS. If RES and XRES have the same value the UE has successfully authenticated itself to the network and the NAS signaling connection can proceed.

At this point, after successful authentication, it is time to activate the NAS security functions: namely, NAS ciphering and NAS integrity protection. Thus, the MME sends the NAS security mode command message to the UE including the security key Kasme received previously from the HSS, and the algorithms for EPS encryption and EPS integrity protection that have been selected from the UE capability list and will be used to secure this NAS signaling connection.

After the UE has received the NAS security command, it computes on behalf of the assigned EPS encryption/integrity algorithms and the Kasme key the keys for NAS encryption and NAS integrity protection that are identical to those already stored in the MME. Now NAS security is in service the UE sends back the NAS security mode complete message, which is the encrypted and integrity protected NAS message. It is not mandatory to use NAS encryption and integrity protection. It is always up to the operator to decide what is required to secure the network.

After the NAS security functions are in service, the underlying RRC connection and the ciphering for user plane traffic need to be activated. For this purpose, first a so-called security context is installed between the MME and eNB. Since security is not the only context-related information to be exchanged between these two network elements, the S1AP initial context setup message will also contain other parameters besides the UE security capabilities and the eNB's security key K_eNB. Note that the UE security capabilities so far are unknown to the eNB.

Now the eNB derives the keys for RRC encryption (K_RRCenc), RRC integrity protection (K_RRCint), and user plane encryption (K_UPenc) from K_ASME. Then the eNB sends the RRC security mode command message to the UE. This message contains the AS encryption algorithm and AS integrity protection algorithm bundled with the START parameters for the AS security activation procedure.

The UE computes the keys for RRC encryption (K_RRCenc), RRC integrity protection (K_RRCint), and user plane encryption (K_UPenc) from the K_ASME together with the received keys and activates the requested security functions using these parameters. After successful activation, the UE sends the RRC security mode complete message (i.e., ciphered and/or integrity protected) back to the eNB. And the eNB confirms the successful establishment of the security context to the MME by sending the S1AP successful outcome message for the procedure code "Initial Context Setup."

QoS Architecture | Standards, Protocols, and Functions

The EPS bearer service layered architecture is depicted in Figure 1. Besides the different names of bearers and reference points, this architecture does not look very different from the bearer service architecture defined in Release 99. However, there is a major difference that is not obvious at first sight.

 
Figure 1: LTE QoS architecture (according to 3GPP 23.401). Reproduced with permission from © 3GPP™

In 3G UMTS the request of a subscriber for a defined QoS of an end-to-end service starts the QoS negotiation procedure. This depends on the subscriber's subscribed QoS stored in the HLR and the available network resources which QoS is granted to a particular connection at the end. The QoS negotiation and control process starts on the NAS layer with the first SM message sent by the UE.

In LTE – different to 2.5 and 3G PS connections – a default bearer with a default QoS is already established when the UE attaches to the network. The QoS attributes of this default bearer are determined by the subscribed QoS parameters stored in the HSS. This is still as seen in 2.5/3G networks.

However, if now the first user plane packet is sent by the UE it is routed toward the PDN where the PCRF analyzes the requested end-to-end service. Depending on this service, the PCRF may now trigger a modification of QoS parameters in all the involved bearers. There is no option for the subscriber to request a particular QoS; only the network is in charge of QoS control. There is also no way for the UE to request something known as a secondary context in 3G (see Section 3.26 in Kreher and Ruedebusch, 2007). In LTE all QoS management is tied to the application, not to SM signaling.

It is important to understand that one UE in LTE can have multiple end-to-end services active and each of these services will have its own individual bearer. It is not intended by LTE standards that, for example, non-real-time services like web-browsing and e-mail will be mapped onto the same bearer (e.g., the same S1-U GTP tunnel) as we have seen in 3G UMTS. For this reason also 256 individual E-RABs for a single UE can be addressed by E-UTRAN protocols while in UMTS only 15 different RAB-IDs had been defined by the standard organizations.

In the 3GPP specs there is also a Traffic Flow Template (TFT) mentioned for the UL as well as for the DL part of the connection. These TFTs are bound to the EPS bearers. In general, a TFT can be described as a set of filters for a particular end-to-end service. Each TFT consists of a destination IP address and a set of source/destination port numbers. On the DL, the IP address is the address assigned to the UE; on the UL, it is the address of a server on the PDN. If we assume, for example, an HTTP 1.1 end-to-end service, the DL TFT of this service consists of the UE's IP address, the TCP source port number is 80, and the TCP destination port number is 80. On the UL, the port numbers are the same, but the IP address is the address of the server that hosts the web site.

To standardize the QoS handling, a set of nine QCIs have been defined by 3GPP. There are four classes with a Guaranteed Bit Rate (GBR) and five classes with a Non-Guaranteed Bit Rate (Non-GBR).

Besides the bit rate, the parameter priority, packet delay budget, and packet error loss rate are critical factors as given in Table 1.

Table 1: Standardized QCI, QoS parameter thresholds, and example services (according to 3GPP 23.203). Reproduced with permission from © 3GPP™ 

QCI	Resource type	Priority	Packet delay budget (ms)	Packet error loss rate	Example services
1	GBR	2	100	10−2	Conversational voice
2		4	150	10−3	Conversational video (live streaming)
3		3	50	10−3	Real-time gaming
4		5	300	10−6	Non-conversational video (buffered streaming)
5	Non-GBR	1	100	10−6	IMS signaling
6		6	300	10−6	Video (buffered streaming) TCP based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)
7		7	100	10−3	Voice, video (live streaming) interactive gaming
8		8	300	10−6	Video (buffered streaming) TCP based
9		9			(e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)