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.)

User Equipment

As in UMTS, the LTE mobile station is called User Equipment (UE). It is constructed using a modular architecture that consists of three main components (see Figure 1):

• Mobile Termination: The MT represents termination of the radio interface. In this entity the RRC signaling is terminated and RRC messages are sent/received.
• Terminal Adapter: The terminal adapter represents the termination of the application-specific service protocols, for example, SIP signaling for VoIP. The terminal adapter might be constructed as an external interface, for example, USB to connect a laptop PC using LTE technology with a mobile network.
• Terminal Equipment: The TE represents termination of the service. Depending on the UE's application capabilities, it may act as the TE or not. For instance, the Apple iPhone with its browser functionalities has full TE capability while a simple USB stick for mobile data transmission has no TE capability at all. In the case of the USB stick, the connected laptop PC is the TE.
  
  

 
Figure 1.: Modular architecture of a UE

1) UE Categories

The UE categories stand for an abstract grouping of common UE radio access capabilities and are defined in 3GPP 36.306.

In particular, the handset-type groups vary in maximum possible throughput (the maximum number of DL-SCH transport blocks bits received within a Time Transmission Interval (TTI)). Assuming a TTI of 1 ms for category 1, the maximum possible throughput is 10 296 bits/1 ms which is approximately 10Mbps of physical layer DL throughput (including the RLC/MAC header information-so the payload throughput will be slightly less).

Category 5 mobiles are the only handsets that support 64 Quadrature Amplitude Modulation (QAM) on the UL as highlighted in Tables 1 and 2. The maximum possible bit rate ranges from 5 Mbps (Cat. 1) to 75 Mbps (Cat. 5).

Table 1: UE categories and DL capabilities (according to 3GPP 36.306). Reproduced with permission from © 3GPP™ 

UE category	Maximum number of DL-SCH transport block bits received within a TTI	Maximum number of bits of a DL-SCH transport block received within a TTI	Approximate maximum bit rate DL (Mbps)
Category 1	10 296	10 296	10
Category 2	51 024	51 024	50
Category 3	102 048	75 376	75
Category 4	150 752	75 376	75
Category 5	302 752	151 376	150

Table 2: UE categories and UL capabilities (according to 3GPP 36.306). Reproduced with permission from © 3GPP™ 

UE category	Maximum number of bits of an UL-SCH transport block transmitted within a TTI	Support for 64QAM in UL	Approximate maximum bit rate UL (Mbps)
Category 1	5 160	No	5
Category 2	25 456	No	25
Category 3	51 024	No	50
Category 4	51 024	No	50
Category 5	75 376	Yes	75

Access Point Name

In the GPRS backbone, an Access Point Name (APN) is a reference to a GGSN. To support inter-PLMN roaming, the internal GPRS DNS (Domain Name System) functionality is used to translate the APN into the IP address of the GGSN.

In the EPC network the APN is found in GTP-C signaling when packet contexts are established, but it is no longer found in LTE NAS signaling. This means in turn that for 2.5G and 3G phones the APN is an important parameter to be stored on the (U)SIM card, but for 4G phones the APN does not need to be configured by the end user. This will also resolve the problem where many PDP context setup failures seen currently in the GERAN and UTRAN are due to an unknown or missing APN.

The APN is composed of two parts as follows:

• The APN network identifier; this defines to which external network the GGSN is connected and optionally a requested service by the MS. This part of the APN is mandatory.
• The APN operator identifier; this defines in which PLMN GPRS backbone the GGSN is located. This part of the APN is optional.

The APN operator identifier is placed after the APN network identifier. An APN consisting of both the network identifier and operator identifier corresponds to the DNS name of a GGSN; the APN has, after encoding as defined below, a maximum length of 100 octets.

The encoding of the APN follows the name syntax defined in RFC 2181 [18], RFC 1035 [19], and RFC 1123 [20]. The APN consists of one or more labels. Each label is coded as a one-octet length field followed by that number of octets coded as 8-bit ASCII characters. Following RFC 1035 [19], the labels should consist only of the alphabetic characters (A–Z and a–z), digits (0–9), and the hyphen (-). Following RFC 1123 [20], the labels should begin and end with either an alphabetic character or a digit. The case of alphabetic characters is not significant. The APN is not terminated by a length byte of zero.

Typical APNs are:

• mms.tim.net;
• wap.eplus.net;
• wap.beeline.ru;
• wap.debitel.de;
• web.vodafone.de;
• internet.t-mobile.

The APN of a 3G subscriber is stored in the USIM. In LTE NAS signaling the APN is no longer used, because it is chosen by the intelligent packet routing functions of MME. However, the APN Average Maximum Bit Rate (APN-AMBR) may be signaled to the UE by the MME to control the amount and bandwidth of UL traffic.

Mapping between Temporary and Area Identities for EUTRAN- and UTRAN/GERAN-Based Systems

For the construction of the RA update request message in GERAN/UTRAN or TA update request message in E-UTRAN the following identities should be included.

In GERAN and UTRAN the RAI is constructed from the MCC, MNC, LAC, and RAC. In addition, the routing area update request message contains the P-TMSI that includes the mapped Network Resource Identifier (NRI) that is used in Iu flex networks. (An example of NRI usage is given in Kreher and Ruedebusch, 2007.)

P-TMSI should be of 32-bit length where the two topmost bits are reserved and always set to 11. These are needed since the GERAN representation of P-TMSI, of the form TLLI (Temporary Logical Link Identity), imposes this restriction. Hence, for a UE which may hand over to GERAN/UTRAN (based on subscription and UE capabilities), the corresponding bits in the M-TMSI are set to 11.

The NRI field is of variable length and should be mapped into the P-TMSI starting at bit 23 and down to bit 14. The most significant bit of the NRI is located at bit 23 of the P-TMSI regardless of the configured length of the NRI.

In the case of a combined MME-SGSN node, the NRI of the SGSN part and the MMEC of the MME part refer to the same combined node. The RAN configuration allows NAS messages on GERAN/UTRAN and E-UTRAN to be routed to the same combined node. The same or different values of NRI and MMEC may be used for a combined node.

The mapping of the GUTI should be done to a combination of the RAI of GERAN/UTRAN and the P-TMSI as follows:

E-UTRAN <MCC>	maps to GERAN/UTRAN <MCC>
E-UTRAN <MNC>	maps to GERAN/UTRAN <MNC>
E-UTRAN <MME Group ID>	maps to GERAN/UTRAN <LAC>
E-UTRAN <MME Code>	maps to GERAN/UTRAN <RAC>

It is also copied into the eight most significant bits of the NRI field within the P-TMSI. E-UTRAN <S-TMSI> maps as follows:

• 22 bits of the E-UTRAN <M-TMSI> starting at bit 30 and down to bit 9 are mapped into the remaining 22 bits of the GERAN/UTRAN <P-TMSI>;
• the remaining 8 bits of the E-UTRAN <M-TMSI> are copied into 8 bits of the <P-TMSI signature> field.

For the UTRAN, the 10-bit-long NRI bits are masked out from the P-TMSI and also supplied to the RAN node as an Intra-Domain NAS Node Selector (IDNNS).

The mapping of P-TMSI (TLLI) and RAI in GERAN/UTRAN to GUTI in E-UTRAN should be performed as follows:

GERAN/UTRAN <MCC>	maps to E-UTRAN <MCC>
GERAN/UTRAN <MNC>	maps to E-UTRAN <MNC>
GERAN/UTRAN <LAC>	maps to E-UTRAN <MME Group ID>
GERAN/UTRAN <RAC>	maps to 8 bits of the M-TMSI

The eight most significant bits of GERAN/UTRAN <NRI> map to the MMEC.

GERAN/UTRAN <P-TMSI or TLLI> excluding the eight most significant bits at the NRI position maps to the remaining bits of the M-TMSI.

The values of <LAC> and <MME group id> should be disjoint, so that they can be differentiated. It is recommended that the most significant bit of the <LAC> be set to zero, and the most significant bit of <MME group id> set to one.

RNTI

In 3G UMTS the Radio Network Temporary Identifiers (RNTIs) are always used to identify information dedicated to a particular subscriber on the radio interface, especially if common or shared channels are used for data transmission. Now, in LTE it is the rule that common channels and shared channels are used to transmit all UE-specific data, but also some network-specific data across the radio interface. For this reason the RNTI in LTE is not always related to a particular subscriber, but sometimes also used to distinguish broadcast network information from data streams of subscribers.

The RNTI is signaled in the MAC layer.

When MAC uses the Physical Downlink Control Channel (PDCCH) to indicate radio resource allocation, the RNTI that is mapped on the PDCCH depends on the logical channel type:

• C-RNTI, Temporary Cell Radio Network Temporary Identifier (temp C-RNTI), and Semi-Persistent Scheduling (SPS) C-RNTI for Dedicated Control Channel (DCCH) and DTCH;
• Paging Radio Network Temporary Identity (P-RNTI) for Paging Control Channel (PCCH);
• Random Access Radio Network Temporary Identifier (RA-RNTI) for Random Access Response (RAR) on DL-SCH;
• Temporary C-RNTI for Common Control Channel (CCCH) during the random access procedure;
• System Information Radio Network Temporary Identifier (SI-RNTI) for Broadcast Control Channel (BCCH).

All RNTIs are encoded using the same 16-bit format (two octets = 2 bytes).

The following values (given in Table 1) are defined for the different types of RNTI.

Table 1: RNTI values (according to 3GPP 36.321). Reproduced with permission from © 3GPP™ 

Value (hexadecimal)		RNTI
FDD	TDD
0000-0009	0000-003B	RA-RNTI
000A-FFF2	003C-FFF2	C-RNTI, semi-persistent scheduling C-RNTI, temporary C-RNTI, TPC-PUCCH-RNTI, and TPC-PUSCH-RNTI
FFF3-FFFC		Reserved for future use
FFFE		P-RNTI
FFFF		SI-RNTI

1 P-RNTI

The P-RNTI is the 4G complement of the paging indicator known from 3G UMTS. It does not refer to a particular UE, but to a group of UEs.

The P-RNTI is derived from the IMSI of the subscriber to be paged and constructed by the eNB. For this reason the IMSI is transmitted in a S1AP paging message from the MME to eNB, although in other S1 signaling only the GUTI is used to mask the true identity of the subscriber.

2 RA-RNTI

The RA-RNTI is assigned by the eNB to a particular UE after this UE has sent a random access preamble on the Physical Random Access Channel (PRACH). If this random access preamble is received by the eNB and network access granted, the base station sends an acquisition indication back to the mobile and this acquisition indication message contains the RA-RNTI. In turn the UE will use the RA-RNTI to send a RRC connection request message on the radio interface UL and the parameter will help to distinguish messages sent by different UEs on the Random Access Channel (RACH).

3 C-RNTI

The C-RNTI is a 16-bit numeric value. Its format and encoding are specified in 3GPP 36.321 (MAC). The C-RNTI is part of the MAC Logical Channel Group ID field (LCG ID). It defines unambiguously which data sent in a DL direction within a particular LTE cell belongs to a particular subscriber. For instance, all RRC messages belonging to a single connection between a UE and the network are marked with the same C-RNTI value by the MAC entity that provided transport services to the RRC and NAS. Thus, C-RNTI is an important parameter for call tracing.

The C-RNTI comes in three different flavors: temp C-RNTI, semi-persistent scheduling C-RNTI, and permanent C-RNTI.

The temp C-RNTI is allocated to the UE during random access procedure (with a RRC connection setup message) and may turn into a permanent C-RNTI depending on the result of a subsequently performed contention resolution procedure or in the case of contention-free random access.

The semi-persistent scheduling C-RNTI is used if the subscriber is running services with a predictable unchanging QoS profile. A typical example is VoIP for which the required bit rate will not change during the entire connection. In such a case the dynamic (re)scheduling of radio resources, which is mandatory in the case of bursty payload traffic to ensure optimal usage of resource blocks, is not required. The SPS C-RNTI is used to indicate an area of resource blocks that will be used by the same UE for a longer time frame without any expected change.

4 SI-RNTI

The SI-RNTI is sent on the PDCCH. It does not stand for a particular UE identity. Instead it signals to all mobiles in a cell where the broadcast System Information Blocks (SIBs) are found on the Physical Downlink Shared Channel (PDSCH). This is necessary since the PDSCH is used to transport both broadcast system information for all UEs and signaling/payload for particular mobiles. In other words, the SI-RNTI indicates which DL resource blocks are used to carry SIBs that in 3G UMTS have been sent on the broadcast (transport) channel mapped onto the Primary Common Control Physical Channel (P-CCPCH). In LTE there is no CCPCH, only DL-SCH.

GUTI | Area and Subscriber Identities

The GUTI is assigned only by the MME during initial attach of a UE to the E-UTRAN.

The purpose of the GUTI is to provide an unambiguous identification of the UE that does not reveal the UE or the user's permanent identity in the E-UTRAN. It also allows identification of the MME and network to which the UE attaches. The GUTI can be used by the network to identify each UE unambiguously during signaling connections.

The GUTI has two main components: the Globally Unique Mobility Management Entity Identifier (GUMMEI) that uniquely identifies the MME which allocated the GUTI; and the M-TMSI that uniquely identifies the UE within the MME that allocated the GUTI. The GUMMEI is constructed from the MCC, MNC, and Mobility Management Entity Identifier (MMEI).

The MMEI should be constructed from a Mobility Management Entity Group ID (MMEGI) and a MMEC. The GUTI should be constructed from the GUMMEI and the M-TMSI as shown in Figure 1.

 

Figure 1: Format of GUTI and S-TMSI

For paging purposes, the mobile is paged with the S-TMSI. The S-TMSI is constructed from the MMEC and the M-TMSI. It is correct to say that the S-TMSI is a shorter format of GUTI that can be used because, after successful registration of a UE, the serving network as well as the serving MME group are known and stored in the core network databases.

The operator needs to ensure that the MMEC is unique within the MME pool area and, if overlapping pool areas are in use, unique within the area of overlapping MME pools.

The GUTI should be used to support subscriber identity confidentiality and, in the shortened S-TMSI form, to enable more efficient radio signaling procedures (e.g., paging and service request).

MCC and MNC should have the same field size as described for the IMSI.

The M-TMSI has a length of 32 bits, MMEGI is 16 bits in length, and MMEC 8 bits in length.

It is important to understand that on the S1 interface the IMSI is typically not seen, just like the GUTI. Exceptions are initial attach to the network when no old GUTI is stored on the USIM card or the true subscriber's identity is checked using NAS signaling, which regularly happens when roaming subscribers attach. Also, in the case of the paging procedure the IMSI might be seen.

For monitoring and network performance measurement the IMSI on S1 can only be revealed if the changing temporary identities are tracked with a quite sophisticated architecture. Full IMSI tracking can only be ensured by monitoring all S1 interfaces of an operator's E-UTRAN and ideally all S6a interfaces and storing the current GUTI/IMSI relations in a central point as stored in the HSS.

LMSI, TMSI, P-TMSI, M-TMSI, and S-TMSI | Area and Subscriber Identities

All temporary subscriber identities, Local Mobile Subscriber Identity (LMSI), TMSI, and P-TMSI, will not be seen in E-UTRAN signaling as long as there is no inter-RAT mobility between the E-UTRAN and UTRAN/GERAN. Indeed, for LTE a new NAS protocol was specified (3GPP 24.301) that introduces a new temporary subscriber identity for the E-UTRAN: the GUTI described in Section 1.4.4. However, to fulfill inter-RAT mobility requirements TMSI, P-TMSI, and LMSI will still be found in E-UTRAN NAS messages, or at least it will be indicated if valid values of these parameters are stored on the USIM card.

The LMSI is a four-octet/byte number. It is a pointer to a database record for a particular IMSI in the Visitor Location Register (VLR) database. Although the VLR is no longer found in the EPC network architecture, there is a database with the same function hosted by the MME. The purpose of the LMSI was to speed up the search for particular database records. If this is still required, with the new powerful computer hardware used to build today's network elements it is a design detail to be defined by NEMs. From definitions given in 3GPP 23.003 it can be guessed that the LMSI will not be used by the MME.

The TMSI is also encoded as a four-octet/byte hex number. It is allocated to a particular subscriber (more correctly, to a particular subscriber's (U)SIM card) during initial attach. The TMSI is used to mask the true subscriber's identity, which is the IMSI, in NAS signaling procedures. In the E-UTRAN it is often used together with the GUTI. It can be coded using a full hexadecimal representation. Since the TMSI has only local significance (i.e., within a VLR and the area controlled by a VLR, or within a SGSN and the area controlled by a SGSN, or within a MME and the area controlled by a MME), the structure and coding of it can be chosen by agreement between the operator and manufacturer in order to meet local needs.

The TMSI allocation procedure should always be executed in ciphered mode to prevent unauthorized eavesdropping.

The P-TMSI is the complement of TMSI in the UTRAN/GERAN PS domain. It is allocated by the SGSN and, hence, will be monitored in the EPC and E-UTRAN during inter-RAT handover/relocation preparation and execution. The P-TMSI is encoded in the same way as the TMSI. The difference is in defining value ranges. If the first two leading digits have the value "11" the parameter is identified as a P-TMSI. Thus, in the hexadecimal format, all TMSI values starting with C, D, E, or F as the first hex number are P-TMSIs.

The M-TMSI is a 32-digit binary number that is part of the GUTI and exclusively used in the E-UTRAN.

The S-TMSI consists of the Mobility Management Entity Code (MMEC) and M-TMSI. Indeed, it is just a shorter variant of the GUTI.