3rd generation partnership project (3GPP) is a “de facto standard body”. It is not the only organization of this kind; let us quote OMA for the mobile services, 3rd generation partnership project 2 (3GPP2) for the Qualcomm CDMA IS95 system, and IEEE with its very successful 802 series. More selective for the choice of its members is “liberty alliance”. And there are plenty of others, with a more or less long lifetime.
ITU-T has been the only worldwide body for telecommunication standards since 1866. International Telecommunication Union (ITU) has the possibility to consider the proposals rising from regional standardization bodies, which are backed by their state, like ANSI for the United States. ETSI was established by the European Union in order to fulfill this kind of task.
“De facto standard bodies” are popping up and proliferating due to the will of industry and of the operators, without any recognition from the legal authorities. Nevertheless, the work they are realizing makes technology progress.
The development of the Global System for Mobile communication (GSM) standard in the 1980s has been obtained essentially through a common work of state owned laboratories, in the framework of post and telecommunication administrations, such as CNET in France and FTZ in Germany.
When the continuation of the drafting of various change requests was transferred to European Telecommunication Standard Institute (ETSI), it was returning somehow to the normal process.
To elaborate the post-GSM standards, there was no suitable body because the aim of the promoters of Universal Mobile Telecommunications System (UMTS) was to associate non-European actors of the mobile business, in fact Chinese, North American, Japanese and South Korean representatives. The aim was to associate all the world’s actors in the mobile business.
Therefore, the European manufacturers and mobile operators had to find a trick. They used a possibility offered by the ETSI rules a way it was not expected: the creation of a kind of temporary ad hoc group dedicated to a precise project, which was called 3GPP1. With the consensus of operators and manufacturers, the 3GPP was created in 1998. Of course, this 3GPP had no precise mandate at the beginning. At its first meeting, the delegates had to define the tasks and elaborate the rules. The short document settling the scope and objectives of 3GPP for its today’s activity has been signed in 2007.
As a first legacy work, the 3GPP inherited the ETSI task of standardizing the evolution of GSM, now denominated global system for mobile communications. Among this evolution, the big inclusions have been general packet radio service (GPRS), then enhanced data rates for GSM evolution (EDGE).
3GPP had to provide contributions to the ITU work on the so called IMT 2000 project, and further to IMT advanced.
Organization | Country | |
European Telecommunications Standards Institute | ETSI | Europe |
Telecommunication Technology Committee | TTC | Japan |
Association of Radio Industries and Businesses | ARIB | Japan |
Alliance for Telecommunications Industry Solutions | ATIS | USA |
China Communications Standards Association | CCSA | China |
Telecommunications Technology Association | TTA | Korea |
The 3GPP is presented as a collaboration working group between different standard bodies specialized in telecommunication. These organizations are called the organizational partners.
These six 3GPP organizational partners meet regularly and ensure the completion of the following tasks:
In fact, the standardization work has been done by experts coming from prominent mobile operators and from industry leaders. There has been no contribution from universities or academic research centers.
The big contributions came from the mobile operators. Among them, the most active have been:
For the industry counterpart, contributions mainly came from:
The standards, at least at the beginning, are based on the GSM core specifications and the already available software, which had been successfully developed already, making GSM fully operational in 1998. It would have been crazy not to take advantage of the already optimized subsystems, such as the MAP. The mobile application part (MAP) is an SS7 protocol that provides an application layer for the various nodes in GSM and UMTS mobile core networks and GPRS core networks to communicate with each other in order to provide services to mobile phone users. The MAP is the application-layer protocol used to access the home location register (HLR), visitor location register, mobile switching center (MSC), equipment identity register, authentication centre, short message service center and serving GPRS support node (SGSN).
From an agreement of all the organizational partners, ETSI hosts the “mobile competence center” (MCC) in Sophia Antipolis. This MCC has the task of keeping the whole standard documentation updated. MCC support team is also ensuring the logistics of the various 3GPP meetings, which take place in the different countries where they are invited. The MCC experts serve for a limited duration. They come from different countries, but the core team is composed of British citizens.
The 3GPP organizational partners invite different market representation partners to provide advices on the market tendencies or requirements for the mobile communication business, mainly services, features and functionalities. These market representation partners have to sign the partnership project agreement, by which they commit themselves to all or part of 3GPP scope. They have no capability, nor authority to define, publish or set standards within the 3GPP scope, nationally or regionally. To date, these market representation partners include:
Organization | Purpose | Website |
IMS Forum | IMS dvpt | imsforum |
TD-Forum | TDSCDMA system | tdscdma |
GSA | GSM industry representatives | gsacom |
GSM Association | GSM operators | gsmworld |
IPV6 Forum | IPV6 | ipv6forum |
UMTS Forum | WCDMA | umts |
4G Americas | 4G for America | 4gamericas |
TD SCDMA Industry Alliance | TDSCDMA system | dscdma |
Info Communication Union | icu | |
Small Cell Forum (formerly Femto Forum) | Femtocells | smallcellforum |
CDMA Development Group | cdg | |
Cellular Operators Association of India (COAI) | Operators in India | coai |
Next Generation Mobile Networks (NGMN) | ngmn | |
TETRA and Critical Communications Association (TCCA) | TETRA evolution | tcca |
The highest decision making body in 3GPP is the Project Coordination Group. Is manages the overall timeframe and work progress.
The work of 3GPP is orchestrated around four meetings a year (spring, summer, autumn and winter) of four technical specification groups (TSG). Three of them meet at the same time and in the same location:
The fourth takes care of GSM, GPRS and EDGE and is called GERAN. It manages independently its agenda and planning.
During the three months between TSG plenary meetings, study groups (up to five per TSG) hold different meetings somewhere in the world in order to study in detail precise items. There are three WG for GERAN, five WG for RAN, four for CT and five for SA.
SA summarizes the whole work. It specifies the service requirements and the overall architecture of 3GPP systems. It is responsible for the coordination of the whole project.
3GPP standardization work is contribution driven. “Individual members”, such as companies bring their contribution, officially under the umbrella of one particular organization partner. For each of the TSG meetings, the number of participants exceeds one hundred experts. For SA meetings, it reaches 200 or more. This important contribution shows the interest of most of the telecommunication actors in obtaining as soon as possible specifications of efficient mobile systems. These experts provide “change requests” to the standards, either to propose a modification or to mend errors. At each TSG meeting, hundreds of CR are presented and discussed.
3GPP follows the three stage methodology that has been defined by ITU-T recommendation I.130:
3GPP also include test specifications, which describe how to verify the compliance of the industrial realization.
Specifications are then put into releases that present each a set of features and specifications, which is internally consistent.
Each release is frozen at a precise freezing date. Once it is frozen, only essential corrections are allowed.
Each release is composed of hundreds of individual standard documents. Each document may have supported many revisions. Current 3GPP standards include the latest version of GSM, UMTS and Long-Term Evolution (LTE) standards.
Each year, in December, the meetings of TSG SA with an active contribution of MCC set the situation of the standards. When possible, the corpus is considered sufficiently coherent to be called a release.
Releases of 3GPP follow more or less a yearly time frame.
Release | Date | Features |
Release 98 | 1Q1999 | GSM features with AMR, EDGE and GPRS for PCS 1900 |
Release 99 | 1Q2000 | First UMTS 3G network specification with WCDMA air interface |
Release 4 | 1Q2001 | UMTS with added features, including all-IP core network |
Release 5 | 1Q2002 | UMTS with IMS and HSDPA |
Release 6 | 1Q2004 | Integrated operation with wireless LAN networks; HSUPA; MBMS; enhancements to IMS; push to talk over cellular (PoC); GAN |
Release 7 | 1Q2007 | Decreased latency; improvements to QoS and realtime applications (such as VoIP); focus on HSPA+ (High Speed Packet Access evolution); SIM highspeed protocol and contactless front end interface (near-field communication, enabling operators to deliver contactless services like mobile payments); EDGE evolution |
Release 8 | 4Q2008 | First LTE release; All-IP network; new OFDMA based radio interface; FDE; MIMO; no backwards compatibility with previous CDMA interfaces; dual cell HSPA |
Release 9 | 4Q2009 | SAES enhancements; WIMAX and LTE/UMTS interoperability; dual cell HSPDA with MIMO; dual cell HSUPA |
Release 10 | 1Q2011 | LTE advanced fulfilling IMT advanced 4G requirements backwards compatible with release 8 LTE; multi cell HSDPA with 4 carriers |
Release 11 | 3Q2012 | Advanced IP interconnection of services; service layer interconnection between national operators/carriers as well as third party application providers; heterogeneous networks (HetNet) improvements; coordinated multipoint operation (CoMP; in-device coexistence |
Release 12 | 3Q2014 | Group calls (GCSE); proximity services (ProSe) |
Release 13 | 1Q2016 | Push to talk (MCPTToLTE; IOPS) |
Release 14 | TBD | TBD |
Step by step, 3GPP worked on the introduction of an “all IP protocol” to provide “wireless internet”.
3GPP standards can be obtained freely on 3GPP’s website. 3GPP specifications are transposed into deliverables by the Organizational Partners, e.g. ETSI for Europe, which edit the corresponding “EN” European standards.
As far as the links with ITU-T and ITU-R are concerned, 3GPP corresponds directly with ITU. In annex is a copy of the submission of 3GPP LTE release 10 and beyond under step 3 of the IMT-advanced process.
An LTE network area is divided into three different types of geographical areas.
Area and description | |
1 | The MME pool area Within this is area the mobile can move without a change of serving MME. Every MME pool area is controlled by one or more MMEs on the network |
2 | The S-GW service area Area served by one or more serving gateways (S-GW). No change of serving gateway inside the S-GW area. |
3 | The tracking area (TA) Similar to the location and routing areas of UMTS and GSM. They give the location of mobiles for incoming calls (mobiles in standby mode). They are not overlapping |
The Mobility Management Entity (MME) pool areas and the S-GW service areas both include many tracking areas. A LTE PLMN topology comprises many MME pool areas, many S-GW service areas and many tracking areas.
The network itself will be identified using public land mobile network identity (PLMN-ID) that will have a three digit mobile country code (MCC) and a two or three digit mobile network code (MNC). For example, the MCC for the UK is 234, while Vodafone’s UK network uses a MNC of 15.
Each MME has three main identities. An MME code (MMEC) uniquely identifies the MME within all the pool areas. A group of MMEs is assigned an MME group identity (MMEGI), which works along with MMEC to make MME identifier (MMEI). A MMEI uniquely identifies the MME within a particular network.
If we compile PLMN-ID with the MMEI then we arrive at a globally unique MME identifier (GUMMEI), which identifies an MME anywhere in the world.
Each tracking area has two main identities. The tracking area code (TAC) identifies a tracking area within a particular network and if we combining this with the PLMN-ID then we arrive at a Globally Unique Tracking Area Identity (TAI).
Each cell in the network has three types of identity. The E-UTRAN cell identity (ECI) identifies a cell within a particular network, while the E-UTRAN cell global identifier (ECGI) identifies a cell anywhere in the world.
The physical cell identity, which is a number from 0 to 503 and it distinguishes a cell from its immediate neighbors.
The international mobile equipment identity (IMEI) is a unique identity for the mobile equipment and the international mobile subscriber identity (IMSI) is a unique identity for the UICC and the USIM. It is provided by the manufacturer. The PLMN records it in the EIR data base.
The M temporary mobile subscriber identity (M-TMSI) identifies a mobile to its serving MME. Adding the MME code in M-TMSI results in an S temporary mobile subscriber identity (S-TMSI), which identifies the mobile within an MME pool area.
Finally, adding the MME group identity and the PLMN identity with S-TMSI results in the globally unique temporary identity (GUTI).
The LTE specification provides downlink peak rates of 300 Mbit/s, uplink peak rates of 75 Mbit/s and Quality-of-Service (QoS) provisions permitting a transfer latency of less than 5 ms in the RAN. LTE has the ability to manage fast-moving mobiles and supports multicast and broadcast streams. LTE access network supports scalable carrier bandwidths, from 1.4 MHz to 20 MHz and also supports both frequency division duplexing (FDD) and time division duplexing (TDD). LTE’s Internet Protocol (IP)-based network architecture supports seamless handovers for both voice and data. The simpler architecture results in lower operating costs (for example, each E-UTRA cell will support up to four times the data and voice capacity supported by High Speed Packet Access (HSPA)).
LTE has been designed to be a successor of GSM and UMTS, taking into account the enormous improvement of digital components. The following schema from 3GPP describes the evolution from GSM to LTE via UMTS.
Due to the progress of digital processors, especially integrated circuits, DSP, FPGA and other, LTE is able to manage its network with a flat packet only RAN architecture.
LTE follows the 3GPP architecture with:
Long-Term Evolution (LTE) is a complex technology. LTE relies on a novel radio access and its non-radio aspects are based on a new paradigm, called system architecture evolution (SAE), which includes the evolved packet core (EPC) network. LTE is an evolution of the GSM/UMTS standards. The goal of LTE was to increase the capacity and speed of wireless data networks using new digital signal processing (DSP) techniques and modulations that were developed around the turn of the millennium. A further goal was the redesign and simplification of the network architecture to an IP-based system with significantly reduced transfer latency compared to the 3G architecture. The whole LTE system is also called evolved packet system (EPS).
For voice calls, the mobile networks that have both LTE and GSM/UMTS elements, the interfaces are as follows:
Overall control of the UE within the LTE architecture is handled by the core network. The core network (known as EPC in the SAE architecture of LTE) is also responsible for establishing the bearers.
Since the EPS2 only provides a bearer path associated with a certain QoS, control of multimedia applications such as VoIP is provided by the IP multimedia subsystem (IMS), which is considered to be outside the EPS itself.
The EPC is composed of routers. It is completely compliant with Internet standards. This is called “full IP”. The main components of the EPC are:
Other essential functions and nodes within the EPC include:
The different LTE network elements are dedicated to control or transmission functions and linked together and with the outside world accordingly.
EPS relies heavily on bearers. The EPS uses these bearers to route IP traffic from a gateway in the packet data network (PDN) to the UE. A bearer is an IP packet flow with a defined QoS between the gateway and the UE. These bearers allow Internet access. They also run services such as voice over IP (VoIP), and are associated with a QoS level.
Multiple bearers can be established for a user in order to provide different QoS streams or connectivity to different PDNs. For example, a user might be engaged in a VoIP call while at the same time performing web browsing or FTP download.
All the above interfaces, of the S series are detailed in 3GPP standards. Their monitoring can be very useful to troubleshoot disfunctioning of the signaling.
Coming into a more detailed study of LTE’s key network element, four different cases are to be considered.
The normal connection of LTE with other telecommunication networks is ensured by a high-speed internet link to some fixed IP network.
To ensure fallback compatibility with GSM, UMTS and CDMA2000, direct links and signaling protocols have been designed.
The architecture becomes therefore a little more complicated, when entering into details. The 3GPP standard includes the connection of LTE networks with former mobile systems, WCDMA (and GSM) as well as CDMA2000.
The access network of LTE, known as eUTRAN, consists of a flat network of eNodeBs. For normal, user traffic, there is no centralized controller in eUTRAN; therefore the eUTRAN architecture is considered flat. The eNodeBs are interconnected with each other by an interface known as “X2” and to the EPC by the S1 interface — more specifically, to the MME by the S1-MME interface, and to the S-GW by the S1-U interface.
The eUTRAN is described in detail further in this chapter. OFDMA is the main topic of Chapter 3.
For all those connections, 3GPP has described standardized interfaces.
Of course, a great variety of mobile terminals are made available. Their telecommunication functions are strictly standardized by 3GPP. It is expected that most of them will be smartphones, taking advantage of the excellent Internet link accessible on the move. In that case, the smartphones include GPS receiver and Wi-Fi connection capabilities.
In the 3GPP vocabulary, the mobile terminal is called UE. The UE is any device used directly by an end-user to communicate, such as a hand-held telephone, a laptop computer equipped with a mobile broadband adapter (dongle or “key”), or any other device (e.g. M2M connecting appliance).
For LTE, the UE connects to the base station eNodeB as specified in the 3GPP 36-series of specifications (ETSI standards 136-series).
The radio interface between the UE and the eNodeB is called LTE-Uu.
The UE handles the following tasks toward the core network:
The corresponding protocols are transmitted transparently via an eNode B, that is, eNode B does not change, use or understand the information. These protocols are also referred to as non-access stratum protocols.
For price reasons, LTE standard offers the possibility to use five different classes of mobiles:
All LTE terminals must be able to operate on the standardized bandwidths:
At the beginning of 2008, all LTE mobiles get the telephony service via circuit switched fall back (CSFB): they take the telephony on a 3G network when available (and if they have the functionality, not useful for internet keys).
Voice on LTE (VOLTE) is offered with release 12.
Introduced inside the UE, LTE has standardized the USIM, which ensures privacy and provides the keys to connect to the network.
The main aim of LTE has been to reduce considerably the latency for the Internet access as well as providing an increased throughput.
The claimed performances of LTE are as follows:
Of course, these performances suppose the availability of 2 × 20 MHz frequency sub-bands for the LTE eNodeB. Multi-antenna technology multiple input multiple output (MIMO) has to be implemented both in the mobile terminal and in the eNodeB.
NOTE.– the above-mentioned bit rates have to be shared between all the subscribers who are active under the coverage of the cell. Imagine 200 customers, at full activity, they obtain 15 MHz downlink and 375 kbps uplink. Better than ADSL but less than FTTH. These top performance values need the implementation of MIMO 4 × 4 both at the eNodeB and mobile. The available bitrates also decrease when the mobile is moving and in poor reception conditions (cell limit). Also, both the network and the UE have to be able to support these maximum bitrates.
LTE architecture supports hard QoS, with end-to-end QoS and guaranteed bit rate (GBR) for radio bearers. Just as Ethernet and the Internet have different types of QoS, for example, various levels of QoS can be applied to LTE traffic for different applications. Because, the LTE MAC is fully scheduled, QoS is a natural fit.
EPS bearers provide one-to-one correspondence with RLC radio bearers and provide support for traffic flow templates (TFT). There are four types of EPS bearers:
LTE Advanced is a modified standard from the existing LTE, which has been rolled out by tens of operators. LTE Advanced has the capacity to work on a very wide frequency band, i.e. 100 MHz with a target of more than 1 Gbps per cell.
Currently, the standard proposes two variants:
LTE has been designed by 3GPP to operate in 40 E-UTRA operating bands. Notwithstanding the fact that all LTE rolled out networks have chosen a FDD eUTRA, eight possible frequency bands are listed for TDD.
Table 1.12 presents E-UTRA operating bands taken from LTE specification 36.101(v860) Table 5.5.1.
The allocation of frequencies for the new LTE system has been and is still the subject of international battles.
The first battle took place in Geneva for the WRC 2007. US delegates announced that they would allocate the frequency band from 698 MHz to 806 MHz to mobile communications as primary use. The European did not accept to free more than 790–862 MHz from terrestrial television. As compensation, they offered to roll out LTE over 3 GHz, creating problems for satellite communications (C-band).
At the WRC 2012, African and Middle East countries, which are part of Region 1 like Europe, announced that they would allocate the 700 MHz band to mobile communications like in the US. Asia – Pacific (Region 3) followed the proposal. European countries were surprised, but they obtained only the postponement the application of the decision to the WRC 2015.
In between, the US FCC issued its plan for the planification of the 700 MHz band. This plan is incompatible with the 790–862 MHz plan as designed by European countries. Right now, the North American operators count over 100 million LTE subscribers, more than half of the world’s total number. Therefore, the US frequency plan is the basis of mass production of mobiles, which are thus far cheaper than those following the 800 MHz plan for Europe.
Parameters | Description |
Frequency range | UMTS FDD bands and TDD bands defined in 36.101(v860) Table 1.12, given below |
Duplexing | FDD, TDD, half-duplex FDD |
Channel coding | Turbo code |
Mobility | 350 km/h |
Channel bandwidth (MHz) | 1.4 3 5 10 15 20 |
Transmission bandwidth configuration NRB: (1 resource block = 180 kHz in 1 ms TTI) | 6 15 25 50 75 100 |
Modulation schemes | UL: QPSK, 16 QAM, 64 QAM (optional) DL: QPSK, 16 QAM, 64 QAM |
Multiple access schemes | UL: SC-FDMA (single-carrier frequency division multiple access) supports 50 Mbps + (20 MHz spectrum) DL: OFDM (orthogonal frequency division multiple access) supports 100 Mbps + (20 MHz spectrum) |
Multi-antenna technology | UL: multi-user collaborative MIMO DL: T × AA, spatial multiplexing, CDD, max 4 × 4 array |
Peak data rate in LTE | UL: 75 Mbps (20 MHz bandwidth) DL: 150 Mbps (UE Category 4, 2 × 2 MIMO, 20 MHz bandwidth) DL: 300 Mbps (UE category 5, 4 × 4 MIMO, 20 MHz bandwidth) |
MIMO (multiple input multiple output) | UL: 1 × 2, 1 × 4 DL: 2 × 2, 4 × 2, 4 × 4 |
Coverage | 5–100 km with slight degradation after 30 km |
QoS | E2E QOS allowing prioritization of different classes of service |
Latency | End-user latency < 10 ms |
The RAN has included the management of the radio subsystem into the base stations, which are called eNodeB. Exit the RNC of UMTS or the BSC of GSM.
The E-UTRAN architecture consists of eNBs that provide the air interface user plane and control plane protocol terminations toward the UE. On one side, the user plane protocols consist of packet data control plane (PDCP), radio link control (RLC), medium access control (MAC) and Physical Layer (PHY) protocols. On the other side, the control plane protocol refers to the Radio Resource Control (RRC) protocol.
Each of the eNBs is logical network components that serve one or several E-UTRAN cells and are interconnected by the X2 interface. Additionally, Home eNBs (also called femtocells), which are eNBs of lower cost, can be connected to the EPC directly or via a gateway that provides additional support for a large number of HeNBs.
The main functionalities hosted by the E-UTRAN are enumerated as follows:
eNodeBs are linked together directly by links according to the interface X2, which is IP compliant.
They are connected to the EPC at the S-GW using the IP protocol.
The connection with the mobile follows OFDMA. In the downlink, there is a broadcasting of all the information and the mobile will extract the items, which are relevant to it.
In the uplink, the mechanism is a modified version of OFDMA called SC-FDMA. The mobile is allocated some of the frequencies to communicate with the eNodeB.
The antennas from the eNodeB can be locally installed or placed on a different location, linked through an optical fiber link. Typically this link can transfer the transmit/receive function as far as 20 km.
The links between eNodeBs and between eNodeB and EPC build the backhaul of the mobile network. It is a major investment for the operator.
This tool is free to download and use. It models the allocation of downlink resource elements to the set of signals and physical channels. The user can configure each of the variables that have an impact on the allocation of resource elements, e.g. channel bandwidth, number of transmit antennas and cell identity. The tool quantifies the throughput for each modulation scheme and for a range of assumed coding rates.
Support for both FDD and TDD communication systems as well as half-duplex FDD with the same radio access technology.
Support for all frequency bands currently used by IMT systems by ITU-R.
Increased spectrum flexibility: 1.4 MHz, 3 MHz, 5 MHz, 10 MHz, 15 MHz and 20 MHz wide cell frequency allocations are standardized.
Support for cell sizes from tens of meters radius (femto and picocells), up to 100 km (62 miles) radius macrocells using the lower frequency bands in rural areas.
Cell size of 5 km (3.1 miles) radius is the optimal size, 30 km (19 miles) have reasonable performances. Up to 100 km cell sizes offer acceptable performances.
In urban areas, higher frequency bands (such as 2.6 GHz in EU) are used to support high-speed mobile broadband. Cell sizes may be 1 km (0.62 miles) or even less.
Supports at least 200 active data clients in every 5 MHz cell.
Simplified architecture: The network side of E-UTRAN is composed only of eNodeBs.
Support for inter-operation and co-existence with legacy standards (e.g. GSM/EDGE, UMTS and CDMA2000). Users can start a call or transfer of data in an area using an LTE standard, and, should coverage be unavailable, continue the operation without any action on their part using GSM/GPRS or W-CDMA-based UMTS or even 3GPP2 networks such as cdmaOne or CDMA2000).
Packet switched radio interface.
Support for multicast-broadcast single frequency network (MBSFN). This feature can deliver services such as Mobile TV using the LTE infrastructure.
According to 3GPP TR 25.912, E-UTRAN is described as follows:
“The evolved UTRAN consists of eNB, providing the evolved UTRAN U-plane and C-plane protocol terminations towards the UE. The eNBs are interconnected with each other by means of the X2 interfaces. It is assumed that there always exist an X2 interface between the eNBs that need to communicate with each other, e.g., for support of handover of UEs in LTE_ACTIVE. The eNBs are also connected by means of the S1 interface to the EPC (Evolved Packet Core). The S1 interface supports a many-to-many relation between GWs and eNBs.”
This general design has a variant in case of deployment of HeNodeB (home eNB, or femtocell). Femtocells do not always have a direct link to MME nor S-GW.
The X2 interface enables eNodeBs de to communicate directly between each other, which is good for interference management (especially in HetNets) and seamless handover.
The X2 interface is defined between two neighbor eNBs. Figure 1.15 shows the control and user plane protocol stack of the X2 interface.
Both X2 and S1 are logical interface i.e. they do not need to be connected directly with one (physical) cable. As can be read in 3GPP specs, they run over IP. So, even though you see X2 interface as a direct connection from one eNB to another eNB, in the real case it might be going to same backhaul as S1.
In the Release-8/9 of 3GPP, X2 interface between small cells and between small cells and macrocells was not available. In Release-10 and 11 (and further), it was made available.
More details on this enhancement is available in 3GPP TS 36.300.
X2 is not only useful for lossless handovers in LTE/LTE-A but is also very useful for Interference management using enhanced Inter Cell Interference Management (eICIC), a feature introduced in Rel-10.
The E-UTRAN uses a simplified single-node architecture consisting of the eNodeBs (E-UTRAN Node B). The eNodeB communicates with the evolved packet core (EPC) using the S1 interface; specifically with the MME and the user plane entity (UPE) identified as S-GW using S1-C and S1-U for control plane and user plane respectively. The MME and the UPE are preferably implemented as separate network nodes so as to facilitate independent scaling of the control and user plane. Also the eNB communicates with other eNB using the X2 interface (X2-C and X2-U for control and user plane respectively).
LTE supports an option of multicast/broadcast over a single frequency network (MBSFN), where a common signal is transmitted from multiple cells with appropriate time synchronization. The eNB being the only entity of the E-UTRAN supports all the functions in a typical radio network such as radio bearer control, mobility management, admission control and scheduling. The access stratum resides completely at the eNB.
The radio protocol architecture for LTE can be separated into control plane architecture and user plane architecture as shown below:
At user plane side, the application creates data packets that are processed by protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP) and IP, while in the control plane, the radio resource control (RRC) protocol writes the signaling messages that are exchanged between the base station and the mobile. In both cases, the information is processed by the packet data convergence protocol (PDCP), the radio link control (RLC) protocol and the medium access control (MAC) protocol, before being passed to the physical layer for transmission.
The user plane protocol stack between the e-Node B and UE consists of the following sublayers:
On the user plane, packets in the core network (EPC) are encapsulated in a specific EPC protocol and tunneled between the P-GW and the eNodeB. Different tunneling protocols are used depending on the interface. GPRS Tunneling Protocol (GTP) is used on the S1 interface between the eNodeB and S-GW and on the S5/S8 interface between the S-GW and P-GW.
Packets received by a layer are called service data unit (SDU) while the packet output of a layer is referred to by protocol data unit (PDU) and IP packets at user plane flow from top to bottom layers.
The control plane includes additionally the radio resource control layer (RRC) that is responsible for configuring the lower layers.
The control plane handles radio-specific functionality which depends on the state of the UE which includes two states: idle or connected.
Mode | Description |
Idle | The user equipment camps on a cell after a cell selection or reselection process, where factors like radio link quality, cell status and radio access technology are considered. The UE also monitors a paging channel to detect incoming calls and acquire system information. In this mode, control plane protocols include cell selection and reselection procedures. |
Connected | The UE supplies the E-UTRAN with downlink channel quality and neighbor cell information to enable the E-UTRAN to select the most suitable cell for the UE. In this case, control plane protocol includes the Radio Link Control (RRC) protocol. |
The different protocols can also be categorized in their layer level:
Physical layer carries all information from the MAC transport channels over the air interface. It takes care of the link adaptation (AMC), power control, cell search (for initial synchronization and handover purposes) and other measurements (inside the LTE system and between systems) for the RRC layer.
MAC layer is responsible for mapping between logical channels and transport channels, multiplexing of MAC SDUs from one or different logical channels onto transport blocks (TB) to be delivered to the physical layer on transport channels, demultiplexing of MAC SDUs from one or different logical channels from transport blocks (TB) delivered from the physical layer on transport channels, scheduling information reporting, error correction through HARQ, priority handling between UEs by means of dynamic scheduling, priority handling between logical channels of one UE, logical channel prioritization.
RLC operates in three modes of operation:
RLC layer is responsible for transfer of upper layer PDUs, error correction through ARQ (only for AM data transfer), concatenation, segmentation and reassembly of RLC SDUs (only for UM and AM data transfer).
RLC is also responsible for resegmentation of RLC data PDUs (Only for AM data transfer), reordering of RLC data PDUs (only for UM and AM data transfer), duplicate detection (only for UM and AM data transfer), RLC SDU discard (only for UM and AM data transfer), RLC re-establishment, and protocol error detection (only for AM data transfer).
The main services and functions of the RRC sublayer include broadcast of system information related to the non-access stratum (NAS), broadcast of system information related to the access stratum (AS), paging, establishment, maintenance and release of an RRC connection between the UE and E-UTRAN, security functions including key management, establishment, configuration, maintenance and release of point to point radio bearers.
PDCP Layer is responsible for header compression and decompression of IP data, transfer of data (user plane or control plane), maintenance of PDCP sequence numbers (SNs), in-sequence delivery of upper layer PDUs at re-establishment of lower layers, duplicate elimination of lower layer SDUs at re-establishment of lower layers for radio bearers mapped on RLC AM, ciphering and deciphering of user plane data and control plane data, integrity protection and integrity verification of control plane data, timer-based discard, duplicate discarding, PDCP is used for SRBs and DRBs mapped on DCCH and DTCH type of logical channels.
The non-access stratum (NAS) protocols form the highest stratum of the control plane between the UE and MME.
NAS protocols support the mobility of the UE and the session management procedures to establish and maintain IP connectivity between the UE and a PDN GW.
Since information is processed by the different protocols, there is the need for a logical channel to follow the different packet contents in order to recover at the end the initial data stream. At the top level, IP packets structure the data flow, at the physical level, the information is mapped into slots, which are assembled into transport blocks.
From top to bottom:
To reduce the useless information of the packet, LTE eUTRAN allows us to the packet a temporary token that replaces the IP header, thus diminishing considerably the size of the data flow to be transmitted.
The information flows between the different protocols are known as channels and signals. LTE uses several different types of logical, transport and physical channel, which are distinguished by the kind of information they carry and by the way in which the information is processed.
Logical channels define what type of information is transmitted over the air, e.g. traffic channels, control channels, system broadcast, etc. Data and signaling messages are carried on logical channels between the RLC and MAC protocols. These channels define the datatransfer services offered by the MAC layer. Data and signaling messages are carried on logical channels between the RLC and MAC protocols.
Logical channels can be divided into control channels and traffic channels:
Logical channels are distinguished by the information they carry and can be classified in two ways. First, logical traffic channels carry data in the user plane, while logical control channels carry signaling messages in the control plane. Following table lists the logical channels that are used by LTE:
The transport channel processor applies several types of control information, to support the low-level operation of the physical layer.
The information travels as far as the transport channel processor in the receiver, but is completely invisible to higher layers. Similarly, the physical channel processor creates physical signals, which support the lowest level aspects of the system.
The base station also transmits two other physical signals, which help the mobile acquire the base station after it first switches on. These are known as the primary synchronization signal (PSS) and the secondary synchronization signal (SSS).
The physical control format indicator channel (PCFICH) is one of the control channels that works at physical layer. It is used to dynamically indicate the number of symbols to be used for PDCCH.
With the help of the PCFICH channel, following scenarios are possible:
PCFICH signaled value depends on channel bandwidth. For channel bandwidth of 3MHz up to 20 MHz, it can carry value of 1, 2 or 3. But for 1.4 MHz, channel bandwidth it can carry value of 2, 3 or 4. Because, in the case of 1.4 MHz bandwidth, there are few subcarriers in the frequency domain. Therefore, more space is required in the time domain to carry PDCCH symbols.
PCFICH occupies 16 resource elements in frequency domain. These resource elements are divided into groups of four quadruplets distributed within first OFDMA symbol of each 1 ms subframe. The exact position of PCFICH can be measured from cell ID and bandwidth using formula given in 3GPP spec 36.211 as below.
where
NRBSC = number of frequency carriers per resource block
NDLRB = number of resource blocks per bandwidth
NcellID = physical cell id
It may look complicated but let us try to understand it with simple example.
Suppose:
Physical Cell id = 20
Bandwidth = 10 Mhz (NDLRB = 50)
According to 3GPP formula:
k_Bar = (12/2).(20 mod 2*50) = 6*20 = 120
Then the four PCFICH mapping values are:
120
120 + (50/2)*(12/2) = 270
120 + 2*(50/2)*(12/2) = 420
120 + 3*(50/2)*(12/2) = 570
The LTE physical layer is based on the orthogonal frequency division multiplexing (OFDM) scheme to meet the targets of high data rate and improved spectral efficiency. The spectral resources are allocated/used as a combination of both time slots and frequency units (aka subcarrier). MIMO options with two or four antennas is supported. Multiuser MIMO is supported in both UL and DL. The modulation schemes supported in the downlink and uplink are QPSK, 16QAM and 64QAM.
The downlink transmission uses the OFDM with cyclic prefix. Some of the reasons for using OFDM are given below:
LTE uses all the time on the downlink for conveying data. The downlink PHY is fully scheduled. There are no gaps due to arbitration or contention, except for the initial access on the random access procedure.
The downlink carries multiple logical channels over one link. A lot of information is multiplexed together in one transport block, as opposed to other networks where any given packet is multiplexed together in one transport block, for both the control plane and the user plane.
The following pilot signals are defined for the DL physical layer:
The uplink transmission uses the single-carrier FDMA (SC-FDMA) scheme. The SC-FDMA scheme is realized as a two stage process where the first stage transforms the input signal to frequency domain (represented by DFT coefficients) and the second stage converts these DFT coefficients to an OFDM signal using the OFDM scheme. Because of this association with OFDM, the SC-FDMA is also called as DFT-spread OFDM. The reasons (in addition to those applicable for OFDM for downlink) for this choice are given below:
Following pilot signals are defined for the UL channel:
Initial draft of the RLC [3GPP TS 36.322] and MAC [3GPP TS 36.321] specifications are available. The hybrid-ARQ is strongly suggested at the MAC layer in addition to the ARQ at the RLC layer.
The LTE link-layer protocols abstract the physical layer and adapt its characteristics to match the requirements of the higher layer protocols. They are optimized to provide low delay and low overhead.
All the following functions are assigned to eNodeB(s) in the E-UTRAN:
S1 interface uses SCTP/IP and GTP-U/UDP/IP for the control and user plane, respectively. The signaling protocol between eNB and MME is identified by S1-AP.
Radio resource management includes transmission power management, mobility management and scheduling of radio resource.
In particular, the management of interferences between OFDMA and SC-FDMA carriers allocated to the different base station cells is a key to manage the capacity.
Multiple input multiple output (MIMO) is an antenna technology processing the signal received by 2 or more receiving antennas and also processing the transmitted signal. Making use of 2 transmitting antennas, or more, the first implementation of MIMO on an operational system was on the Japanese deployment.
MIMO sends multiple streams on multiple transmit antennas – practically 2 or 4 – each stream travels on different paths. The processing allows us to enhance the quality of reception at the other side.
MIMO was first standardized in 3GPP Release 6 (Rel-6). It was then developed in Rel-7 with spatial multiplexing double transmit adaptive array (D-TxAA).
The first MIMO transmission for the LTE network (2 × 2 closed loop SM) was considered to increase by 20%. The downlink sector spectral efficiency compared to a single antenna transmission and increasing the all edge efficiency by some 35%.
The 3GPP Rel-9 LTE specifications include some of the most advanced forms of MIMO of any standard in the industry. 3GPP has since included even more advanced MIMO enhancements for LTE-Advanced.
LTE has designed a variety of cell sites, with macrocells (for distant mobiles), microcells (for hot spots) and pico cells/femtocells (for connection at home). Assembling all these components builds a heterogeneous network with eNodeBs transmitting/receiving with different power levels and possibly different frequencies. For a coverage of wide areas, macrocells and 700 MHz should be preferred. For picocells and femtocells, quasi-Wi-Fi frequencies (e.g. 2.6 GHz) may facilitate the mastering of heavy traffic loads on hotspots. Microcells offer a complement to the macrocell layer when there is locally a shortage of capacity. The problem of the microcell layer is its cost (many sites, important backhaul) as well as the difficult interworking with the macrocell layer.
This coverage paradigm is called heterogeneous network (HetNet).
Following the trend imposed by smartphone manufacturers, LTE cannot ignore the competition of Wi-Fi as a final radio link, especially when the subscriber takes advantage of the high-speed Internet link that is provided at home by some provider, which is not necessarily the operator of the LTE system.
The evolved architecture comprises evolved UTRAN (E-UTRAN) on the access side and evolved packet core (EPC) on the core side. Figure 1.32 shows the evolved system architecture included in the surrounding non-LTE environment, as well as the problematic of roaming:
3GPP does not specify which non-3GPP technologies should be considered trusted or untrusted. This decision is made by the operator.
The architecture of LTE shows only three subsystems:
The eNodeBs are interconnected with each other by means of the X2 interface. The eNodeBs are connected by the S1 interface to the evolved packet core (EPC). The eNodeB connects to the MME by means of the S1-MME interface and to the S-GW by means of the S1-U interface. The S1 interface supports a many-to-many relation between MMEs /S-GWs and eNodeBs.
The interfaces between the different parts of the system are denoted by Uu, S1 and SGi.
eNodeB (eNB) is the base station network element. It interfaces with the UE ( i.e. the mobile) and hosts the PHYsical (PHY), medium access control (MAC), radio link control (RLC) and packet data control protocol (PDCP) layers. It also hosts radio resource control (RRC) functionality corresponding to the control plane. It performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated UL QoS, cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of DL/UL user plane packet headers.
The MME is in charge of managing and storing uE context (for idle state: uE/user identities uE mobility state, user security parameters). It produces temporary identities and allocates them to uE. It checks the authorization whether the UE may camp on the TA or on the PLMN. 23.401 General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access. Usually, the address of HSS is configured in MME statically.
LTE does not offer Gb-Flex similar function between MME and HSS. The purpose for Gb-Flex is to balance load between MMEs and make the network strong. But HSS is just a huge data base, it does not process any call.
Basically, the HSS is a database that contains user-related and subscriber-related information. It also provides support functions in mobility management, call and session setup, user authentication and access authorization. It is the concatenation of the home location register (HLR) and the authentication center (AuC) – two functions being already present in pre-IMS 2G/GSM and 3G/UMTS networks. The HLR part of the HSS is in charge of storing and updating when necessary the database containing all the user subscription information, including (list is non-exhaustive):
The AuC part of the HSS is in charge of generating security information from user identity keys. This security information is provided to the HLR and further communicated to other entities in the network. Security information is mainly used for:
The number of HSS is not big, usually less than 10 in a country (in most countries, less than three).
The gateways (S-GW and PDN GW) deal with the user plane. They transport the IP data traffic between the UE and the external networks. The S-GW is the point of interconnect between the radioside and the EPC. As its name indicates, this gateway serves the UE by routing the incoming and outgoing IP packets.
S-GW routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and PDN GW).
PDN GW provides connectivity of the UE to external PDNs by being the point of exit and entry of traffic for the UE. A UE may have simultaneous connectivity with more than one PDN GW for accessing multiple PDNs. The PDN GW performs policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening [WIK 14b].
Policy and charging rules function (PCRF) server is in charge of managing the service policy and sending QoS setting information for each user session and accounting rule information. The PCRF server groups functionalities for the policy decision function (PDF) and the charging rules function (CRF).
The PDF is the network entity where the policy decisions are made. As the IMS session is being set up, SIP signaling containing media requirements are exchanged between the terminal and the P-CSCF. At some time in the session establishment process, the PDF receives those requirements from the P-CSCF and makes decisions based on network operator rules. For example, it allows or rejects the media request uses new or existing PDP contexts and checks the allocation of new resources.
The CRF provides operator-defined charging rules applicable to each service data flow. The CRF selects the relevant charging rules based on information provided by the P-CSCF, such as application identifier, type of stream (audio, video, etc.) and application data rate, etc.
With reference to 3GPP Ref: TS 23. 401v, 841, the list of LTE interfaces is:
S1-MME interface between eNodeB and MME.
Reference point for the control plane protocol between E-UTRAN and MME.
where:
S1 application protocol (S1-AP): application layer protocol between the eNodeB and MME.
Stream control transmission protocol (SCTP): this protocol guarantees delivery of signaling messages between MME and eNodeB (S1). SCTP is defined in RFC 4960.
S3 interface between SGSN and MME.
It enables user and bearer information exchange for inter 3GPP access network mobility in idle and/or active state.
Where:
GPRS tunneling protocol for the control plane (GTP-C): this protocol tunnels signaling messages between SGSN and MME.
User datagram protocol (UDP): this protocol signaling messages. UDP is defined in RFC 768.
S4 interface between SGSN and Serving Gateway (SGW).
It provides related control and mobility support between GPRS core and the 3GPP anchor function of S-GW. In addition, if direct tunnel is not established, it provides the user plane tunneling.
GTP-C (mentioned above): this protocol tunnels signaling messages between SGSN and SGW.
UDP: this protocol transfers signaling messages. UDP is defined in RFC 768.
S5 or S8 interface between SGW and Packet Data Network Gateway (PGW).
S5: it provides user plane tunneling and tunnel management between S-GW and PDN GW. It is used for S-GW relocation due to UE mobility and if the S-GW needs to connect to a non-collocated PDN GW for the required PDN connectivity.
S8: inter-PLMN reference point providing user and control plane between the S-GW in the visited PLMN (VPLMN) and the PDN GW in the home PLMN (HPLMN). S8 is the inter PLMN variant of S5.
The difference between these two interfaces is S5 is being used in one network entity (no roaming scenario), and S8 is being used to connect VPLMN where user is with his HPLMN.
GTP-C: this protocol tunnels signaling messages between S-GW and P-GW.
UDP: this protocol transfers signaling messages between SGW and PGW. UDP is defined in RFC 768.
S10 interface between MME and other MME.
Reference point between MMEs for MME relocation (e.g. handover) and MME to MME information transfer.
Where:
GTP-C: this protocol tunnels signaling messages between MMEs.
UDP: this protocol transfers signaling messages between MMEs. UDP is defined in RFC 768.
S11 interface between MME and SGW.
Reference point between MME and Serving GW.
Where:
GTP-C: this protocol tunnels signaling messages between MME and SGW.
UDP: This protocol transfers signaling messages between MME and SGW. UDP is defined in RFC 768.
S6a interface between MME and HSS.
It enables transfer of subscription and authentication data for authenticating/authorizing user access to the evolved system (AAA interface) between MME and HSS.
Where:
Diameter: this protocol supports transferring of subscription and authentication data for authenticating/authorizing user access to the evolved system between MME and HSS (S6a). Diameter is defined in RFC 3588.
SCTP: This protocol transfers signaling messages. SCTP is defined in RFC 4960.
S13 interface between MME and EIR.
It enables UE-EIR.
Where:
Diameter: this protocol supports UE identity check procedure between MME and EIR (S13). Diameter is defined in RFC 3588.
SCTP: this protocol transfers signaling messages. SCTP is defined in RFC 4960.
SBc interface between CBC and eNodeB.
Reference point between CBC and MME for warning message delivery and control functions.
Cell broadcast center (CBC) was a solution for the special requirement of an earthquake and tsunami warning system (ETWS) created for Japan, introduced in Rel. 8. It utilizes the existing interfaces between UE and MME in control plane. In addition, the MME is connected to the CBC via the SBc interface. In LTE/fourth Generation (4G) SBc interface is fully standardized and based on SCTP.
Where:
SBc Application Protocol (SBc-AP): application layer protocol between CBC and MME. This protocol supports transfer of warning messages.
S1 Application Protocol (S1-AP): Application Layer Protocol between the eNodeB and the MME.
SCTP: this protocol guarantees delivery of signaling messages between MME and eNodeB (S1). SCTP is defined in RFC 4960.
S1-U interface between eNodeB and SGW.
Reference point between E-UTRAN and S-GW for the per bearer user plane tunneling and inter eNodeB path switching during handover.
Where:
GTP for the user plane (GTP-U): this protocol tunnels user data between eNodeB and SGW.
UDP: this protocol transfers user data. UDP is defined in RFC 768.
S4 interface between UE with 2G access and PGW.
It provides related control and mobility support between GPRS core and the 3GPP anchor function of S-GW. In addition, if direct tunnel is not established, it provides the user plane tunneling.
Where:
GTP U: this protocol tunnels user data between SGSN and the S GW as well as between the S GW and the P GW in the backbone network. GTP will encapsulate all end user IP packets.
UDP/IP: these are the backbone network protocols used for routing user data and control signaling.
Protocols on the Um and the Gb interfaces are described in TS 23.060.
S4 interface is also being used to connect UE with 3G access and PGW.
S12 interface between UE from 3G network and PGW.
It acts as a reference point between UTRAN the serving GW for user plane tunneling when direct tunnel is established. It is based on the Iu-u/Gn-u reference point using the GTP-U protocol.
Where:
GTP U: this protocol tunnels user data between UTRAN and the S GW as well as between the S GW and the P GW in the backbone network. GTP will encapsulate all end user IP packets
UDP/IP: these are the backbone network protocols used for routing user data and control signaling.
Protocols on the Uu interface are described in TS 23.060.
SGSN controls the user plane tunnel establishment and establish a direct tunnel between UTRAN and S GW as shown in Figure 1.19.
The following diagram shows the functional split between the E-UTRAN and the EPC for an LTE network:
What happens when there is no X2 connection between old and new eNodeB? Answer to that is S1-based handover procedure, which you can find, is described below.
All of this information you can find by reading specific section of 3GPP TS 23.401 document.
As it is now like a little tradition, we will start with high level of abstract image.
This image should look familiar for those who were reading about X2-based handover. The thing what has change in this scenario is that there is lack of connectivity between two eNBs between which UE moves.
That is why, in order to do the handover, the MME has to be involved directly. Here eNodeB is contacting MME, and the target eNodeB address is found from its SGW.
The S1-based handover procedure is used when the X2-based handover cannot be used. The source eNodeB initiates a handover by sending a handover required message over the S1-MME reference point. This procedure may relocate the MME and/or the S-GW. The source MME selects the target MME. The MME should not be relocated during inter-eNodeB handover unless the UE leaves the MME pool area where the UE is served. The MME (target MME for MME relocation) determines if the S-GW needs to be relocated. If the S-GW needs to be relocated, the MME selects the target S-GW.
The source eNodeB decides which of the EPS bearers are subject for forwarding of downlink and optionally also uplink data packets from the source eNodeB to the target eNodeB. The EPC does not change the decisions taken by the RAN node. Packet forwarding can take place either directly from the source eNodeB to the target eNodeB, or indirectly from the source eNodeB to the target eNodeB via the source and target S-GWs (or if the S-GW is not relocated, only the single S-GW).
The availability of a direct forwarding path is determined in the source eNodeB and indicated to the source MME. If X2 connectivity is available between the source and target eNodeBs, a direct forwarding path is available.
If a direct forwarding path is not available, indirect forwarding may be used. The source MME uses the indication from the source eNodeB to determine whether to apply indirect forwarding. The source MME indicates to the target MME whether indirect forwarding should apply. Based on this indication, the target MME determines whether it applies indirect forwarding.
If the MME receives a rejection to an S1 interface procedure (e.g. dedicated bearer establishment/modification/release; location reporting control; NAS message transfer, etc.) from the eNodeB with an indication that an S1 handover is in progress, the MME will reattempt the same S1 interface procedure when either the handover is complete or is deemed to have failed if the MME is still the serving MME, except in case of S-GW relocation.
To minimize the number of procedures rejected by the eNodeB, the MME should pause non-handover related S1 interface procedures (e.g. downlink NAS message transfer, E-RAB setup/modify/release, etc.) while a handover is ongoing (i.e. from the time that a handover required has been received until either the handover procedure has succeeded (handover notify) or failed (handover failure)) and continue them once the handover procedure has completed if the MME is still the serving MME, except in case of S-GW relocation.
If during the handover procedure the MME detects that the S-GW or/and the MME needs be relocated, the MME will reject any PDN GW initiated EPS bearer(s) request received since handover started and will include an indication that the request has been temporarily rejected due to handover procedure in progress. The rejection is forwarded by the S-GW to the PDN GW, with the same indication.
Upon receipt of a rejection for an EPS bearer(s) PDN GW initiated procedure with an indication that the request has been temporarily rejected due to handover procedure in progress, the PDN GW will start a locally configured guard timer. The PDN GW will reattempt the procedure, up to a pre-configured number of times, when either it detects that the handover is completed or has failed using message reception or at expiry of the guard timer.
If emergency bearer services are ongoing for the UE, handover to the target eNodeB is performed independent of the handover restriction list. The MME checks, as part of the tracking area update in the execution phase, if the handover is to a restricted area and if so MME releases the non-emergency bearers.
If the MME receives a rejection from a UE context modification request message with a CS fallback indication from the eNodeB with an indication that an S1 handover is in progress, the MME will resend a UE context modification request message with CS fallback indicator to the target eNodeB when either the handover is complete or to the source eNodeB when the handover is deemed to have failed if the MME is still the serving MME.
The S1-based handover in the normal case is described below:.
Step 1. The source eNodeB decides to initiate an S1-based handover to the target eNodeB. This can be triggered e.g. by no X2 connectivity to the target eNodeB, or by an error indication from the target eNodeB after an unsuccessful X2-based handover, or by dynamic information learnt by the source eNodeB.
Step 2. The source eNodeB sends handover required (direct forwarding path availability, source to target transparent container, target eNodeB identity, CSG ID, CSG access mode, target TAI, S1AP cause) to the source MME. The source eNodeB indicates which bearers are subject to data forwarding. Direct forwarding path availability indicates whether direct forwarding is available from the source eNodeB to the target eNodeB. This indication from source eNodeB can be based on e.g. the presence of X2. The target TAI is sent to MME to facilitate the selection of a suitable target MME. When the target cell is a CSG cell or a hybrid cell, the source eNodeB will include the CSG ID of the target cell. If the target cell is a hybrid cell, the CSG access mode will be indicated.
Step 3. The source MME selects the target MME and if it has determined to relocate the MME, it sends a forward relocation request (FRR) (MME UE context, source to target transparent container, RAN cause, target eNodeB identity, CSG ID, CSG membership indication, target TAI, MS info change reporting action (if available), CSG information reporting action (if available), UE time zone, direct forwarding flag) message to the target MME. The target TAI is sent to the target MME to help it to determine whether S GW relocation is needed (and, if required, aid SGW selection).
The source MME will perform access control by checking the UE’s CSG subscription when CSG ID is provided by the source eNodeB. If there is no subscription data for this CSG ID or the CSG subscription is expired, and the target cell is a CSG cell, the source MME will reject the handover with an appropriate cause.
The MME UE context includes IMSI, ME identity, UE security context, UE network capability, AMBR, selected CN operator ID, APN restriction, S-GW address and TEID for control signaling, and EPS bearer context(s).
An EPS bearer context includes the PDN GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic, APN, Serving GW addresses and TEIDs for uplink traffic, and TI.
RAN cause indicates the S1AP cause as received from source eNodeB.
The source MME includes the CSG ID in the FRR when the target cell is a CSG or hybrid cell. When the target cell is a hybrid cell, the CSG membership indication indicating whether the UE is a CSG member will be included in the FRR message.
The direct forwarding flag indicates if direct forwarding is applied, or if indirect forwarding is going to be set up by the source side.
The target MME will determine the maximum APN restriction based on the APN restriction of each bearer context in the FRR, and will subsequently store the new maximum APN restriction value.
If the UE receives only emergency services and the UE is UICCless, IMSI cannot be included in the MME UE context in FRR message. For emergency attached UEs, if the IMSI cannot be authenticated, then the IMSI will be marked as unauthenticated. Also, in this case, security parameters are included only if available.
Step 4. If the MME has been relocated, the target MME verifies whether the source S-GW can continue to serve the UE. If not, it selects a new S-GW. If the MME has not been relocated, the source MME decides on this S-GW reselection.
If the source S-GW continues to serve the UE, no message is sent in this step. In this case, the target S-GW is identical to the source S-GW.
If a new S-GW is selected, the target MME sends a create session request (bearer context(s) with PDN GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic, serving network, UE time zone) message per PDN connection to the target S-GW. The target S-GW allocates the S-GW addresses and TEIDs for the uplink traffic on S1_U reference point (one TEID per bearer). The target S-GW sends a create session response (S-GW addresses and uplink TEID(s) for user plane) message back to the target MME.
Step 5. The target MME sends handover request (EPS bearers to setup, AMBR, S1AP cause, source to target transparent container, CSG ID, CSG membership indication, handover restriction list) message to the target eNodeB. This message creates the UE context in the target eNodeB, including information about the bearers, and the security context. For each EPS bearer, the bearers to setup includes S-GW address and uplink TEID for user plane, and EPS bearer QoS. If the direct forwarding flag indicates unavailability of direct forwarding and the target MME knows that there is no indirect data forwarding connectivity between source and target, the bearers to setup will include “data forwarding not possible” indication for each EPS bearer. Handover restriction list is sent if available in the target MME.
S1AP cause indicates the RAN cause as received from source MME.
The target MME will include the CSG ID and CSG membership indication when provided by the source MME in the FRR message.
The target eNodeB sends a handover request acknowledge (EPS bearer setup list, EPS bearers failed to setup list target to source transparent container) message to the target MME. The EPS bearer setup list includes a list of addresses and TEIDs allocated at the target eNodeB for downlink traffic on S1 U reference point (one TEID per bearer) and addresses and TEIDs for receiving forwarded data if necessary. If the UE AMBR is changed, e.g. all the EPS bearers, which are associated to the same APN, are rejected in the target eNodeB, the MME will recalculate the new UE-AMBR and signal the modified UE AMBR value to the target eNodeB.
If none of the default EPS bearers have been accepted by the target eNodeB, the target MME will reject the handover.
If the target cell is a CSG cell, the target eNodeB will verify the CSG ID provided by the target MME, and reject the handover with an appropriate cause if it does not match the CSG ID for the target cell. If the target eNodeB is in hybrid mode, it may use the CSG membership indication to perform differentiated treatment for CSG and non-CSG members.
Step 6. If indirect forwarding applies and the S-GW is relocated, the target MME sets up forwarding parameters by sending create indirect data forwarding tunnel request (target eNodeB addresses and TEIDs for forwarding) to the S-GW. The S-GW sends a create indirect data forwarding tunnel response (target S-GW addresses and TEIDs for forwarding) to the target MME. If the S-GW is not relocated, indirect forwarding may be set up in step 8 below.
Indirect forwarding may be performed via an S-GW that is different from the S-GW used as the anchor point for the UE.
Step 7. If the MME has been relocated, the target MME sends a forward relocation response (cause, target to source transparent container, S-GW change indication, EPS bearer setup list, addresses and TEIDs) message to the source MME. For indirect forwarding, this message includes S-GW address and TEIDs for indirect forwarding (source or target). S-GW change indication indicates a new S-GW has been selected.
Step 8. If indirect forwarding applies, the source MME sends a create indirect data forwarding tunnel request (addresses and TEIDs for forwarding) to the Serving GW. If the Serving GW is relocated it includes the tunnel identifier to the target serving GW.
The S-GW responds with a create indirect data forwarding tunnel response (S-GW addresses and TEIDs for forwarding) message to the source MME.
Indirect forwarding may be performed via a S-GW that is different from the S-GW used as the anchor point for the UE.
Step 9. The source MME sends a handover command (target to source transparent container, bearers subject to forwarding, bearers to release) message to the source eNodeB. The bearer’s subject to forwarding includes list of addresses and TEIDs allocated for forwarding. The bearers to release include the list of bearers to be released.
Step 9a. The handover command is constructed using the target to source transparent container and is sent to the UE. Upon reception of this message the UE will remove any EPS bearers for which it did not receive the corresponding EPS radio bearers in the target cell.
Step 10. The source eNodeB sends the eNodeB status transfer message to the target eNodeB via the MME(s) to convey the PDCP and HFN status of the E-RABs for which PDCP status preservation applies. The source eNodeB may omit sending this message if none of the E-RABs of the UE will be treated with PDCP status preservation.
If there is an MME relocation, the source MME sends this information to the target MME via the forward access context notification message, which the target MME acknowledges. The source MME or, if the MME is relocated, the target MME, sends the information to the target eNodeB via the eNodeB status transfer message.
Step 11. The source eNodeB should start forwarding of downlink data from the source eNodeB toward the target eNodeB for bearers subject to data forwarding. This may be either direct (step 11a) or indirect forwarding (step 11b).
Step 12. After the UE has successfully synchronized to the target cell, it sends a handover confirm message to the target eNodeB. Downlink packets forwarded from the source eNodeB can be sent to the UE. Also, uplink packets can be sent from the UE, which are forwarded to the target S-GW and on to the PDN GW.
Step 13. The target eNodeB sends a handover notify (TAI+ECGI) message to the target MME.
Step 14. If the MME has been relocated, the target MME sends a forward relocation complete notification message to the source MME. The source MME in response sends a forward relocation complete acknowledge message to the target MME. Regardless of whether the MME has been relocated or not, a timer in source MME is started to supervise when resources in source eNodeB and if the S-GW is relocated, also resources in source S-GW will be released.
Upon receipt of the forward relocation complete acknowledge message the target MME starts a timer if the target MME allocated S GW resources for indirect forwarding.
Step 15. The MME sends a modify bearer request (eNodeB address and TEID allocated at the target eNodeB for downlink traffic on S1 U for the accepted EPS bearers, ISR activated) message to the target S-GW for each PDN connection, including the PDN connections that need to be released. If the PDN GW requested UE’s location and/or user CSG information (determined from the UE context), the MME also includes the user location information IE and/or user CSG information IE in this message. If the UE time zone has changed, the MME includes the UE time zone IE in this message. For the case where neither MME nor S-GW changed, if ISR was activated before this procedure, MME should maintain ISR. The UE is informed about the ISR status in the tracking area update procedure.
The MME releases the non-accepted dedicated bearers by triggering the bearer release procedure. If the S-GW receives a DL packet for a non-accepted bearer, the S-GW drops the DL packet and does not send a downlink data notification to the MME.
If the default bearer of a PDN connection has not been accepted by the target eNodeB and there are other PDN connections active, the MME will handle it in the same way as if all bearers of a PDN connection have not been accepted. The MME releases these PDN connections by triggering the MME requested PDN disconnection procedure.
When the modify bearer request does not indicate ISR activated the S-GW deletes any ISR resources by sending a delete bearer request to the other CN node that has bearer resources on the S-GW reserved.
Step 16. If the S-GW is relocated, the target S-GW assigns addresses and TEIDs (one per bearer) for downlink traffic from the PDN GW. It sends a modify bearer request (S-GW addresses for user plane and TEID(s), serving network) message per PDN connection to the PDN GW(s). The S-GW also includes user location information IE and/or UE time zone IE and/or user CSG information IE if they are present in step 15. The S-GW allocates DL TEIDs on S5/S8 even for non-accepted bearers. The PDN GW updates its context field and returns a modify bearer response (charging Id, MSISDN) message to the target S-GW. The MSISDN is included if the PDN GW has it stored in its UE context. The PDN GW starts sending downlink packets to the target GW using the newly received address and TEIDs. These downlink packets will use the new downlink path via the target S-GW to the target eNodeB.
If the S-GW is not relocated, but has received the user location information IE and/or UE time zone IE and/or user CSG information IE from the MME in step 15, the S-GW will inform the PDN GW(s) about these information that, e.g., can be used for charging, by sending the message modify bearer request (user location information IE, UE time zone IE, user CSG information IE) to the PDN GW(s) concerned. A modify bearer response message is sent back to the S-GW.
If the S-GW is not relocated and it has not received user location information IE nor UE time zone IE nor user CSG information IE from the MME in step 15, no message is sent in this step and downlink packets from the S-GW are immediately sent on to the target eNodeB.
Step 17. The target S-GW sends a modify bearer response message to the target MME. The message is a response to a message sent at step 15.
If the S-GW does not change, the S-GW will send one or more “end marker” packets on the old path immediately after switching the path in order to assist the reordering function in the target eNodeB.
Step 18. The UE initiates a tracking area update procedure when one of the conditions listed in clause “triggers for tracking area update” applies.
The target MME knows that it is a handover procedure that has been performed for this UE as it received the bearer context(s) by handover messages and therefore the target MME performs only a subset of the TA update procedure, specifically it excludes the context transfer procedures between source MME and target MME.
Step 19. When the timer started in step 14 expires the source, MME sends a UE context release command message to the source eNodeB. The source eNodeB releases its resources related to the UE and responds with a UE context release complete message. When the timer started in step 14 expires and if the source MME received the S-GW change indication in the forward relocation response message, it deletes the EPS bearer resources by sending delete session request (cause, LBI) messages to the source S-GW. Cause indicates to the source S-GW that the S-GW changes and the source S-GW will not initiate a delete procedure toward the PDN GW. The source S-GW acknowledges with delete session response messages. If ISR has been activated before this procedure, the cause also indicates to the source S-GW that the source S-GW will delete the bearer resources on the other old CN node by sending delete bearer request message(s) to that CN node.
Step 20. If indirect forwarding was used then the expiry of the timer at source MME started at step 14 triggers the source MME to send a delete indirect data forwarding tunnel request message to the S-GW to release the temporary resources used for indirect forwarding that were allocated at step 8.
Step 21. If indirect forwarding was used and the S-GW is relocated, then the expiry of the timer at target MME started at step 14 triggers the target MME to send a delete indirect data forwarding tunnel request message to the target S GW to release temporary resources used for indirect forwarding that were allocated at step 6.
The target eNodeB rejects the use of the handover procedure if none of the requested bearers in the handover request message could be established. In this case no UE context is established in the target MME/eNodeB and no resources are allocated. Furthermore, the target MME rejects the handover request and clears all resources in target eNodeB and target MME if the target eNodeB accepts the handover request but none of the default EPS bearers receive resources allocated. In both cases, the UE remains in the source eNodeB/MME.
Step 1–5. Steps 1 to 5 in the flow are identical to steps 1–5 mentioned in above scenario.
Step 6a. If the target eNodeB fails to allocate any resources for any of the requested EPS bearers it sends a handover failure (cause) message to the target MME. The target MME clears any reserved resources for this UE in the target MME.
Step 6b. If the target MME receives a handover request acknowledge message from the target eNodeB but none of the default EPS bearers are in the EPS Bearer setup list IE, the target MME clears any reserved resources for this UE in both the target MME and the target eNodeB.
Step 7. This step is only performed for S-GW relocation, i.e. if steps 4/4a have been performed. The target MME deletes the EPS bearer resources by sending delete session request (cause) messages to the target S-GW. The target S-GW acknowledges with delete session response (cause) messages.
Step 8. The target MME sends the forward relocation response (cause) message to the source MME.
Step 9. When the source MME receives the forward relocation response message, it sends a handover preparation failure (cause) message to the source eNodeB.
Instead of completing the handover procedure, the source eNodeB may at any time during the handover procedure, up to the time when a handover command message is sent to the UE cancel the handover.
The MME will cancel the handover resources for cases where the source RAN is eNodeB.
A network run by one operator in one country is known as a public land mobile network (PLMN). For its subscribers, it is the home-PLMN. Roaming is the process that allows users to move outside their home network and get serviced by the resources from another operator’s network, called visited-PLMN.
A roaming user is connected to the E-UTRAN, MME and S-GW of the visited LTE network. However, LTE/SAE allows the P-GW of either the visited or the home network to be used.
The home network’s P-GW allows the user to access the home operator’s services even while in a visited network. A P-GW in the visited network allows a “local breakout” to the Internet in the visited network.
The interface between the serving and PDN gateways is known as S5/S8.
Roaming is one of the fundamental mobility management procedures of all cellular networks, if they support this feature. Roaming is defined as the ability for a cellular customer to automatically make and receive voice calls, send and receive data, or access other services, including home data services, when travelling outside the geographical coverage area of the home network, by means of using a visited network. This can be done by using a communication terminal or else just by using the subscriber identity in the visited network. Roaming is technically supported by mobility management, authentication, authorization and billing procedures [WIK 14a].
Architecture standards describe two ways of dealing with roaming:
Information flow could be divided into two groups:
Mobility management is one of the major functions of all mobile networks. It allows mobile phones – UEs – to work. The aim of mobility management is to track where the subscribers are, allowing calls, SMS and other mobile services to be delivered to them.
LTE, like all cellular networks, is a radio network rolled out with hundreds or thousands of individual cells, known as base stations. Each base station covers a small geographical area that is part of a uniquely identified location area. By integrating the coverage of each of these base stations, a cellular network provides a radio coverage over a much wider area. A group of base stations is called a location area, or a routing area. For LTE, it is the tracking area. A “location area” is a set of base stations that are grouped together to optimize signaling. To each location area, a unique number called a “location area code” is assigned. The location area code is broadcasted by each base station, known at regular intervals. If the location areas are very large, there will be many mobiles operating simultaneously, resulting in very high paging traffic, as every paging request has to be broadcasted to every base station in the location area. This wastes bandwidth and power on the mobile, by requiring it to listen for broadcast messages too much of the time. If on the other hand, there are too many small location areas, the mobile must contact the network very often for changes of location, which will also drain the mobile’s battery. A balance has therefore to be found and the constitution of location areas on the field is an important task of the operator’s radio engineers.
The location update procedure is the process by which a mobile device informs the cellular network when it changes its location. The location code is rear by the mobile. When a mobile finds that the location area code is different from its last update, it performs another update by sending to the network, a location update request, together with its previous location, and the temporary identity it received from the network. Thus a subscriber has reliable access to the network and may be reached with a call.
A mobile will provide updated location information to the network. Whenever a mobile is switched on or off, the network may require it to perform an IMSI attach or IMSI detach location update procedure. Each mobile is required to regularly report its location at a set time interval using a periodic location update procedure. Whenever a mobile moves from one location area to the next while not on a call, a random location update is required. This is also required of a stationary mobile that reselects coverage from a cell in a different location area because of signal fade.
The tracking area is the LTE counterpart of the location area and routing area. A tracking area is a set of cells. Tracking areas can be grouped into lists of tracking areas (TA lists), which can be configured on the UE. Tracking area updates are performed periodically or when the UE moves to a tracking area that is not included in its TA list.
Operators can allocate different TA lists to different UEs. This can avoid signaling peaks in some conditions: for instance, the UEs of passengers of a train may not perform tracking area updates simultaneously.
On the network side, the involved element is the MME. MME configures TA lists using NAS messages like attach accept, TAU accept or GUTI reallocation command.
Non-access stratum (NAS) is a functional layer in LTE wireless telecom protocol stacks between the core network and UE. This layer is used to manage the establishment of communication sessions and for maintaining continuous communications with the UE as it moves. The NAS is defined in contrast to the access stratum that is responsible for carrying information over the wireless portion of the network. A further description of NAS is that it is a protocol for messages passed between the UE, also known as mobiles, and MME, that is passed transparently through the radio network. Examples of NAS messages include update or attach messages, authentication messages, service requests, etc. Once the UE establishes a radio connection, the UE uses the radio connection to communicate with the core nodes to coordinate service. The distinction is that the access stratum is for dialogue explicitly between the mobile equipment and the radio network and the NAS is for dialogue between the mobile equipment and core network nodes. For LTE, the technical standard for NAS is 3GPP TS 24.301 [WIK 14c].
The following functions exist in the non-access stratum:
Subscriber’s identity module (SIM) is an important network element in the GSM system. It mirrors the information used in the authentication center (AUC) and home location register (HLR).
GSM security is a 128 bits security. The Ki key and the A8 algorithm are permanent components of the SIM.
A5 is built in the mobile terminal (ME in the GSM vocabulary). A5 is symmetrically implemented in the base station in order that the communications can be encoded and decoded for their radio transmission.
The Ki is provided to the SIM with the international mobile subscriber identity (IMSI). Both are permanent data that characterize the subscriber – at least the subscription to be billed for the services.
The GSM family, of which LTE is part, defines a set of identifiers:
Mobile country code (MCC): MCC consists of three decimal numbers. It indicates the home country of the mobile subscriber. MCC is composed of three decimal numbers. The coding range is decimal 000–999.
MCC is used in IMSI and location area identity (LAI).
As the unique country identity standard, MCCs are allocated and managed by the ITU. ITU recommendation E.212 (blue book) stipulated the MCC number for every country. Due to the special meaning of MCC, modification of it is prohibited once it has been set in the network.
Mobile network code (MNC): MNC is used to uniquely identify a specific GSM PLMN network in a certain country (decided by MCC). MNC is composed of two decimal numbers. The coding range is decimal 00–99.
MNC is used in IMSI and LAI.
IMSI also contains MNC. It shows the home GSM PLMN network of the subscriber. When MS logs on the network or applies for a certain service, it must report IMSI to the network (when TMSI is unavailable.). The network judges whether this subscriber is a roaming subscriber according to the MNC in IMSI, and uses it as one of the important parameters for addressing to subscriber HLR.
If a country has more than one GSM PLMN, different networks must have different MNC. MNC is allocated by relevant telecommunication management department of the country.
One operator can have one or more MNC (which regards to the scale provided by the service, usually one operator has one MNC). Different operators can share the same MNC. Due to the special meaning of MNC, modification is prohibited once it has been set in the network.
Location area identity (LAI). It is periodically transmitted in system information of each cell. Here, MNC indicates the network number of GSM PLMN. MS uses the received information as an important basis for network selection.
The process for authentication and ciphering has been standardized in detail by 3GPP.
The Kc key, calculated with the A8 algorithm is introduced in the A5 ciphering algorithm, which encrypts the data on the radio path.
Figure 1.62 shows the different contributions to the privacy process of GSM.
RAND is generated by the AUC. Ki is stored in the SIM with the IMSI of the subscriber. The SIM has the A3 algorithm implemented by the network operator during the personalization process.
RAND, SRES and Kc build a triplet. Triplets are provided to the VLR by the HLR/AUC in a limited number. When the VLR becomes dry from triplets, the mobile cannot register, so communications become impossible.
RAND and SRES are the inputs for authentication. Kc via the A5 algorithm ciphers the flow of transmitted data.
A3, A5 and A8 are secret algorithms.
Figure 1.63 shows the size of the components. Basically, the security process of GSM is a 128 bits process.
Ki = individual key for authentication, stored with the IMSI.
SRES = signed response, is the result of a calculation made with the A3 algorithm on RAND and Ki.
The SIM also contains the TMSI, temporary identification, which is allocated to the mobile for a few minutes. TMSI is much shorter than the IMSI and saves radio resource.
TMSI, Kc, RAND and SRES are non-permanent data.
For GSM, the structure of the SIM files is relatively simple. The one for the LTE USIM is shown later and is much more complicated. (see 3GPP TS 51.011)
For 3G (UMTS) and 4G (LTE), 3GPP has divided the SIM in three entities, which of course are part of one smart card:
An IP Multimedia Services Identity Module (ISIM) is an application running on an UICC smart card in the IP Multimedia Subsystem (IMS). Parameters identify and authenticate the user to the IMS. The ISIM application can co-exists with USIM on the same UICC.
ISIM includes an IP Multimedia Private Identity (IMPI), the home operator domain name, one or more IP Multimedia Public Identity (IMPU) and a long-term secret used to authenticate and calculate cipher keys. The first IMPU stored in the ISIM is used in emergency registration requests.
Term | Description |
3GPP | 3rd Generation Partnership Project |
3GPP2 | 3rd Generation Partnership Project 2 |
ARIB | Association of Radio Industries and Businesses |
ATIS | Alliance for Telecommunication Industry Solutions |
AWS | Advanced Wireless Services |
CAPEX | Capital Expenditure |
CCSA | China Communications Standards Association |
CDMA | Code Division Multiple Access |
CDMA2000 | Code Division Multiple Access 2000 |
DAB | Digital Audio Broadcast |
DSL | Digital Subscriber Line |
DVB | Digital Video Broadcast |
eHSPA | evolved High Speed Packet Access |
ETSI | European Telecommunications Standards Institute |
FDD | frequency division duplex |
FWT | fixed wireless terminal |
GSM | Global System for Mobile communication |
HSPA | High Speed Packet Access |
HSS | Home Subscriber Server |
IEEE | Institute of Electrical and Electronics Engineers |
IPTV | Internet Protocol Television |
LTE | Long Term Evolution |
MBMS | Multimedia Broadcast Multicast Service |
MIMO | Multiple input multiple output |
MME | Mobility Management Entity |
NGMN | Next generation mobile networks |
OFDM | Orthogonal frequency division multiplexing |
OPEX | Operational expenditure |
PAPR | Peak-to-average power ratio |
PCI | Peripheral component interconnect |
PCRF | Policing and charging rules function |
PDSN | Packet data serving node |
PS | Packet switched |
QoS | Quality-of-Service |
RAN | Radio access network |
SAE | System architecture evolution |
SC-FDMA | Single-carrier frequency division multiple access |
SGSN | Serving GPRS support node |
TDD | Time division duplex |
TTA | Telecommunications Technology Association |
TTC | Telecommunication Technology Committee |
TTI | Transmission time interval |
UTRA | Universal Terrestrial Radio Access |
UTRAN | Universal Terrestrial Radio Access Network |
WCDMA | Wideband Code Division Multiple Access |
WLAN | Wireless local area network |
In response to the ITU-R Circular Letter 5/LCCE/2, which invites proposals for candidate radio interface technologies for the terrestrial component of IMT-Advanced, the 3GPP is providing a complete submission of LTE release 10 and beyond (LTE-Advanced) under step 3 of the IMT-Advanced process in Document IMT-ADV/2(Rev. 1)
This submission of the 3GPP candidate SRIT (which includes an FDD RIT component and a TDD RIT component) is based on the currently approved work within 3GPP and follows the ITU-R IMT-Advanced submission format and guidelines.
The Proponent3 of the 3GPP submission (hereafter known as the 3GPP Proponent) is providing all the required parts of the complete submission for the first invitation by the final deadline as specified in Document IMT-ADV/2(Rev.1).
The 3GPP proponent has provided all required information within each of required major components either directly or by endorsement of this contribution made by 3GPP individual members on behalf of 3GPP:
The 3GPP proponent is looking forward to continuing dialog with ITU-R WP5D through the entire process of the development of IMT-Advanced.
The “LTE Release 10 & beyond (LTE-Advanced)” candidate technology submission is an SRIT and includes an FDD RIT component and a TDD RIT component.
The versions used are: Report ITU-R M.2133 Requirements, evaluation criteria and submission templates for the development of IMT-Advanced (approved 2008–11); Report ITU-R M.2134 Requirements related to technical performance for IMT-Advanced radio interface(s) (approved 2008–11); Report ITU-R M.2135 Guidelines for evaluation of radio interface technologies for IMT-Advanced (approved 2008–11) and Document ITU-R IMT-ADV/3 Correction of typographical errors and provision of missing texts of IMT-Advanced channel models in Report ITU-R M.2135 (July 2009).
The self-evaluation report of the 3GPP “LTE Release 10 & beyond (LTE-Advanced)” can be found in document 3GPP TR 36.912 v9.0.0, 3GPP; Technical Specification Group Radio Access Network; Feasibility study for Further Advancements for EUTRA (LTE-Advanced) (Release 9), section 16.
3GPP provides in Attachment 1 additional supporting information in document 3GPP TR 36.912 v9.0.0, 3GGG, Technical Specification Group Radio Access Network; Feasibility study for Further Advancements for EUTRA(LTE-Advanced) (Release 9).
Mr. Takehiro NAKAMURA, Chairman of 3GPP TSG RAN is the Contact Person designated by the 3GPP Proponent for any communication related to this submission.
3GPP TR 36.912 v9.0.0, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Feasibility study for Further Advancements for EUTRA (LTE-Advanced) (Release 9) and related information files.
GTP is present at all levels of LTE.
The GTP stack assigns a unique tunnel endpoint identifier (TEID) to each GTP control connection to the peers. The GTP stack also assigns a unique TEID to each GTP user connection (bearer) to the peers. The TEID is a 32 bit number field in the GTP (GTP-C or GTP-U) packet.
GTP-C allocates a TEID to identify a set of endpoints for a GTP-C tunnel. For each bearer, a separate GTP-U tunnel with its own TEID is established.
An ingress Packet Forwarding Engine performs GTP-C TEID route lookup to identify the target services PIC for the received packet for the following types of GTP-C messages:
Each GTP-U tunnel is also assigned a TEID. For example, the GTP-U tunnel for a default bearer would have its own TEID.
GTP is an important IP/UDP-based protocol used in GSM, UMTS and LTE core networks. It is used to encapsulate user data when passing through core network and also carries bearer specific signaling traffic between various core network entities.
GTP in LTE:
GTP Interfaces in LTE:
In LTE, version 1 is used for GTP-U and version 2 is used for GTP-C.
In simple LTE network implementation, GTP-v2 is used on S5 and S11 interfaces and GTPv1 is used on S1-U, S5, X2-U interfaces (as shown below). In inter-RAT and inter PLMN connectivity, S3, S4, S8, S10, S12 and S16 interfaces also utilize GTP protocols.
GTP-U encapsulation of UE user plane traffic can be easily understood by taking any simple example. Let us see what happens when IP packet generated by UE reaches to eNodeB and is then forwarded to SGW.
Consider any application on UE creates an IP/TCP packet. This packet consist of actual data by application, TCP or UDP header and the IP field information which has source address of UE and destination address of application server (e.g. Facebook).
When the eNodeB receives this packet over air interface, it will put the IP packet inside GTP header which has information related to tunnel IDs. Then further, it is encapsulated inside UDP and IP header and forwarded as Ethernet frame toward SGW. Here the IP header contains eNodeB IP as a source address and SGW IP as a destination address
As GTP-Cv2 in LTE is used for tunnel management, some of the signaling messages are listed below which use GTP-Cv2 protocol.
The following is a list of acronyms used in the Figure in Appendix 3 (section 1.11)
For each UE associated with the EPS, there is a single SGW at any given time.
The Cisco LTE SGW Release 1.x supports GTP-based non-roaming and roaming architectures, and control and data plane functions defined by 3GPP TS 23.401 for 3GPP access networks.
The Cisco LTE SGW provides the following support:
The Cisco LTE SGW runs on the Cisco Service and Application Module for IP (SAMI), a new-generation high-performance service module for the Cisco 7600 Series Router platforms.
For more information about the Cisco SAMI, see the Cisco Service and Application Module for IP User Guide.
This section describes the system requirements for Cisco LTE SGW Release 1.x and includes the following sections:
For hardware requirements, such as power supply and environmental requirements and hardware installation instructions, see the Cisco Service and Application Module for IP User Guide.
Implementing a Cisco LTE SGW Release 1.x on the Cisco 7600 series internet router platform requires the following hardware and software:
Or one of the following Cisco 7600 series Route Switch Processors running Cisco IOS Release 15.0(1)S or later:
For details on upgrading the Cisco IOS release running on the supervisor engine, refer to the “Upgrading to a New Software Release” section in the Release Notes for Cisco IOS Release 15.0S. For information about verifying and upgrading the LCP ROMMON image on the Cisco SAMI, refer to the Cisco Service and Application Module for IP User Guide.
AT&T Inc. now has small cells in the lab that combine 3G, 4G and Wi-Fi and is gearing up for a nationwide launch of the technology that will be part of its HSPA+ network.
“Small cells” have been the blanket term for a new breed of tiny base station that can be used to increase data speeds, voice coverage and network density as data traffic grows. As you will see, for AT&T these little radios will come in several flavors.
The operator’s senior VP of small cells, Gordon Mansfield, was on hand at AT&T’s Innovation Showcase in downtown New York on Thursday morning to give Light Reading Mobile some more insight into the operator’s ambitions. (See AT&T’s Armada: 4G, Small Cells & More.)
“They’re currently in my lab”, Mansfield says of the combo LTE/3G/Wi-Fi small cells. AT&T defines these units as a Multi-Standard Metrocell (MSM). The operator intends for these multimode units to be deployed in public venues with indoor and outdoor versions that support up to 64 simultaneous calls.
LR Mobile asked Mansfield when the MSM units will start to move out of the lab and onto the network. “It would be foolish to think less than a year” but probably will not take two years, he said.
Metrocells that will increase voice coverage and data speeds on AT&T’s HSPA+ network, which it markets as “4G”, are coming much sooner. “We’ve got a significant portion of the country updated”, Mansfield says.
AT&T defines a “Metrocell” as a “4G” unit that can be deployed in big offices or neighborhoods, with indoor and outdoor versions that can support up to 32 simultaneous calls. At the showcase event, AT&T was boasting that the metrocells have achieved nearly 100% outdoor coverage in Crystal Park Lake, MO. The Crystal Park Lake area is a Missouri Class 4 city with a population of around 470 that covers an area of 64 acres. AT&T has also been testing small cells in an enterprise setting in the Milwaukee metro area and a high-rise business setting in NYC.
AT&T had an Alcatel-Lucent 9364 version 2 outdoor microcell on show at the event. Mansfield said that he is looking for both the MSM and metrocell deployments to be multivendor affairs.
Ahead of the nationwide switch-on for the HSPA+ metrocell deployment, AT&T has been working to update its data centers and roll out updates to its mobile switching centers (MSCs) in its core network. The MSCs manage call services for phones roaming in its area.
This is necessary for the phone to work as the user would expect when roaming across the small-cell network. “If they dial 911, it better route to 911 and not somewhere else”, Mansfield notes.
“That’s coming pretty soon”, Mansfield says of these updates.
AT&T has famously – or maybe infamously – said that it will deploy 40,000 small cells by the end of 2015. So, we asked Mansfield how he sees that target moving along.
“At this point I see no reason to believe that we won’t hit that number… and we could revise it next year”, he said.
1 The 3GPP website contains all 3GPP specifications. They can be downloaded for free at http://www.3gpp.org/specifications. Descriptions of all 3GPP releases can be found at http://www.3gpp.org/ftp/Information.
2 3GPP TS 23.002 (http://www.3gpp.org/ftp/Specs/html-...) gives an overview the architecture of the 3GPP system. In particular, it describes all the network elements used in the EPC and also in legacy core networks.
3GPP TS 23.401 (http://www.3gpp.org/ftp/Specs/html-...) defines the architecture of the EPC for E-UTRAN access.
3GPP TS 23.402 (http://www.3gpp.org/ftp/Specs/html-...) defines the architecture enhancements for non-3GPP accesses.
3 The 3GPP Proponent of the 3GPP submission is collectively the 3GPP Organizational Partners (OPs). The Organizational Partners of 3GPP are ARIB, ATIS, CCSA, ETSI, TTA and TTC (http://www.3gpp.org/partners).