Wednesday, November 16, 2011

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

Sunday, November 13, 2011

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

Wednesday, November 9, 2011

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.

Wednesday, November 2, 2011

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.