1

2
There are several domains in EPS each one a grouping of logical nodes that interwork
to provide a specific set of functions in the network.

A network implementing 3GPP specification is illustrated above.

On the left of the diagram are four clouds that represent different RAN domains that
can connect to the EPC, including the second and third generation of mobile access
networks specified by 3GPP, more commonly known as GSM and WCDMA
respectively.

LTE is of course the latest mobile broadband radio access as defined by 3GPP.

Finally there is the domain called non-3GPP access networks. This denotes any packet
data access network that is not defined by 3GPP standardisation processes, e.g.
eHRPD, WLAN, fixed network accesses or some combination of these.

This also means that 3GPP does not specify the details about these access
technologies – these specifications are instead handled by other standardisation
bodies such as 3GPP2, IEEE, or Broadband Forum.

Interworking with these access technologies is discussed later in the course.

3
The diagram above illustrates the complete architecture developed for EPS, together
with the Packet Core domain defined prior to EPC.

It also shows how the connection to this ‘old’ 3GPP packet core is designed (in fact
this specific connection comes in two flavours itself, a fact that adds to the complexity
of the diagram, but more about that later).

The diagram illustrates the complete architecture, including support for

interconnection of just about any packet data network one can think of.

It is unlikely that any single network operator would make use of all these logical
nodes and interfaces; this means that deployment options and interconnect options
are somewhat simplified.

4
The EPC is a new, high-performance, high-capacity all-IP core network for LTE.

EPC addresses LTE requirements to provide advanced real-time and media-rich

services with enhanced Quality of Experience (QoE).

EPC improves network performance by the separation of control and data planes and
through a flattened IP architecture, which reduces the hierarchy between mobile data
elements (for example, data connections from eNodeB only traverse through EPC
gateways).

The diagram shows the EPC as a core part of the all-IP environment of LTE.

The EPC is realized through four new elements:

• Serving Gateway (SG-W)
• Packet Data Network (PDN) Gateway (PGW)
• Mobility Management Entity (MME)
• Policy and Charging Rules Function (PCRF)
While SGW, PGW and MME are introduced in 3GPP Release 8, PCRF was introduced in
3GPP Release 7. Until now, the architectures using PCRF have not been widely
adopted.
The PCRF’s interoperation with the EPC gateways and the MME is mandatory in
Release 8 and essential for the operation of the LTE.

5
Serving Gateway
The SGW is a data plane element whose primary function is to manage user-plane
mobility and act as a demarcation point between the RAN and core networks.

SGW maintains data paths between eNodeBs and the PDN Gateway (PGW).

From a functional perspective, the SGW is the termination point of the packet data
network interface towards E-UTRAN.

When terminals move across areas served by eNodeB elements in E-UTRAN, the SGW
serves as a local mobility anchor.

This means that packets are routed through this point for intra E-UTRAN mobility and
mobility with other 3GPP technologies, such as 2G/GSM and 3G/UMTS.

6
Like the SGW, the Packet Data Network Gateway (PDN GW) is the termination point of
the packet data interface towards the Packet Data Network(s).
As an anchor point for sessions towards the external Packet Data Networks, the PDN
GW supports:
• Policy enforcement features (applies operator-defined rules for resource
allocation and usage)
• Packet filtering (for example, deep packet inspection for application type
detection)
• Charging support (for example, per-URL charging)

In LTE, data plane traffic is carried over virtual connections called service data flows
(SDFs). SDFs, in turn, are carried over bearers — virtual containers with unique QoS
characteristics. The diagram above illustrates the scenario where one or more SDFs
are aggregated and carried over one bearer.

One bearer, a data-path between a UE and a PDN, has three segments:

• Radio bearer between UE and eNodeB
• Data bearer between eNodeB and SGW (S1 bearer)
• Data bearer between SGW and PGW (S5 bearer)
The lower diagram illustrates three segments that constitute an end-to-end bearer.
The primary role of a PGW is QoS enforcement for each of these SDFs, while SGW
focuses on dynamic management of bearers.

7
The Mobility Management Entity (MME) is a nodal element within the LTE EPC.
It performs the signalling and control functions to manage the User Equipment (UE)
access to network connections, the assignment of network resources, and the
management of the mobility states to support tracking, paging, roaming and
handovers.
MME controls all control plane functions related to subscriber and
session management.
MME manages thousands of eNodeB elements, which is one of the key differences
from requirements previously seen in 2G/3G (on RNC/SGSN platforms).
The MME is the key element for gateway selection within the EPC (Serving and PDN).
It also performs signalling and selection of legacy gateways for handovers for other
2G/3G networks. The MME also performs the bearer management control functions
to establish the bearer paths that the UE/ATs use.

The MME supports the following functions:

• Security procedures: End-user authentication as well as initiation and
negotiation of ciphering and integrity protection algorithms.
• Terminal-to-network session handling: All the signalling procedures used to
set up packet data context and negotiate associated parameters like QoS.
• Idle terminal location management: The tracking area update process used
to enable the network to join terminals for incoming sessions.

8
The introduction of the EPC and all-IP network architecture in the mobile network has
profound implications on:
• Mobile services, as all voice, data and video communications are built on the
IP protocol
• Interworking of the new mobile architecture with previous mobile
generations (2G/3G)
• Scalability required by each of the core elements to address dramatic
increases in number of direct connections to user terminals, orders of
magnitude of bandwidth increase, and dynamic terminal mobility
• Reliability and availability delivered by each element to ensure service
continuity
To address a radically different set of network and service requirements, the EPC
must represent a departure from existing mobile networking paradigms.

Three new logical nodes and associated interfaces are added; the PCRF, OCS and
OFCS.
OCFS is short for Offline Charging System and OCS is short for Online Charging System,
both logical entities interface the PDN GW (through the Gz interface and Gy interface
respectively) and support various features related to charging of end-users based om
a number of different parameters such as time, volume, event, etc.

9
The major improvement provided in Release 7 of 3GPP in terms of policy and
charging is the definition of a new converged architecture to allow the optimization of
interactions between the Policy and Rules functions.
The R7 evolution involves a new network node, Policy and Charging Rules Function
(PCRF), which is a concatenation of Policy Decision Function (PDF) and Charging Rules
Function (CRF).
Release 8 further enhances PCRF functionality by widening the scope of the Policy
and Charging Control (PCC) framework to facilitate non-3GPP access to the network
(for example, WiFi or fixed IP broadband access).
In the generic policy and charging control 3GPP model, the Policy and Charging
Enforcement Function (PCEF) is the generic name for the functional entity that
supports service data flow detection, policy enforcement and flow-based charging.
The Application Function (AF) here represents the network element that supports
applications that require dynamic policy and/or charging control.
In the IMS model, the AF is implemented by the Proxy Call Session Control Function
(P-CSCF).
The diagram above shows how PCRF interfaces with other EPC elements.

10
Now LTE and 2G/3G network is connected. Now let's look into the interplay of the
two networks to make the voice call possible.

This interplay can be explained by adding just three lines as shown above:
• Voice call traffic path
• Registration to CS network path
• Paging path

Is this everything to make CS Fallback happen?

There is some difference in terms of signalling protocol between LTE and 2G/3G.

To make these two different protocol work together would not be that simple.

To make this happen, LTE network should have a certain level of understanding
(compatibility) with 2G/3G protocol and 2G/3G network should have a certain level of
understanding LTE protocol.

It is not the scope of this short section to describe the whole details of 'CS Fallback'
protocol side.

11
The IMS (IP Multimedia Subsystem) is a generic platform offering IP-based
multimedia services.

IMS provides functions and common procedures for session control, bearer control,
policy and charging.

IMS is made up of several functional entities that include, Call Session Control
Functions (CSCF), Media Gateway (MGW) nodes and functions, like the Media
Gateway Control Function (MGCF).

These entities allow the platform to interconnect any access network – 2G/3G/UMTS
or EPC, to a set of common multimedia services and the PSTN and IP networks, both
public and private.

It also allows session control to be carried out in the users home network, even when
the user is roaming in another network.

12
13
14
15
16
It must be said that LTE as a radio access technology is flanked by a couple of
significant improvements in the core network known as the EPS.

Simplifying tings a little, it is not wrong to state that EPS is an all-IP transport network
for mobile operators.

IP will also become the physical transport layer on the wired interfaces of the E-
UTRAN.

This all-IP architecture Is also one of the facts behind the bullet point on simplified
network architecture.

However to assume that to be familiar with TCP/IP is enough to understand and

measure LTE would be a fatal error.

While the network architecture and even basic signalling procedures (except
handovers) become simpler, the understanding and tracking of radio parameters
require more knowledge and deeper investigation than they did before.

17
Conditions on the radio interface will change rapidly and with a time granularity of
1ms the radio resources assigned to a particular connection can be adjusted
accordingly.

For instance, the radio quality that is impacted by the distance between the User
Equipment (UE) and base station can determine the modulation scheme and hence
the maximum bandwidth of a particular connection.

Simultaneously the cell load and neighbour cell interference – mostly depending on
the number of active subscribers in that cell – will trigger fast handover procedures
due to changing best serving cell in city centre areas, while in rural areas macro cells
will ensure the bet possible coverage.

The typical footprint of a LTE cell is expected by 3GPP experts to be in the range from
approximately 700m up to 100km.

Surely due to the wave propagation laws such macro cells cannot cover all services
over the entire footprint.

Therefore the service coverage within a single cell will vary, for example from the
inner to the outer areas and the maximum possible bit rates will decline. Service
optimisation will be another challenge.

18
Since the early days two key parameters have driven the evolution of packet services
further toward LTE; higher data rates and shorter latency.

EGPRS (or EDGE) focused mostly on higher data rates, but did not include any latency
or algorithms to guarantee a defined Quality of Service (QoS) in early standardisation
releases.

Meanwhile in parallel to the development of UMTS standards, important

enhancements to EDGE have been defined that allow pre-emption of radio resources
for packet services and control QoS.

Due to its easy integration in existing GSM networks, EDGE is widely deployed today
in cellular networks and is expected to coexist with LTE for the long haul.

Nevertheless the first standard that promised complete control of QoS was UMTS
Release 99. in contrast to the TBFs of EGPRS the user is assigned dedicated radio
resources for PS data that are permanently available through a radio connection.
These resources are called bearers.

In Release 99, when a PDP Context is activated the UE is ordered by the RNC to enter
Radio Resource Control (RRC) CELL_DCH state. Dedicated resources are assigned by
the Serving Radio Network Controller (SRNC): these are the dedicated physical

19
channels established on the radio interface.

Those channels are used for transmission of both IP payload and RRC Signalling as
shown in the diagram overleaf.

RRC signalling includes the exchange of Non-Access Stratum (NAS) messages between
the UE and SGSN.

The spreading factor of the radio bearer (as the combination of several physical
transport resources on the air interface is called) depends on the expected UL/DL IP
throughput.

The expected data transfer rate can be found in the RANAP (Radio Access Network
Application Part) part of the Radio Access Bearer (RAB) assignment request message
that is used to establish the Iu bearer, a GPRS Tunnelling Protocol (GTP) tunnel for
transmission of IP payload on the IuPS interface between the SRNC and SGSN.

While the spreading factor controls the bandwidth of the radio connection, a
sophisticated power control algorithm guarantees the necessary quality of the radio
transmission.

For instance this power control ensures that the number of retransmitted frames
does not exceed a certain critical threshold.

Activation of PDP context results also in the establishment of another GTP tunnel on
the Gn interface between the SGSN and GGSN.

In contrast to IuPS, where the tunnel management is a task of the RANAP, on the Gn
interface – as in EGPRS – the GPRS Tunnelling Protocol – Control (GTP-C) is
responsible for context (or tunnel) activation, modification and deletion.

20
However in Release 99 the maximum possible bit rate is still limited to 384kbps for a
single connection and more dramatically the number of users per cell that can be
served by this highest possible bit rate is very limited (only four simultaneous
384kbps connections per cell are possible on the DL due to the shortness of DL
spreading codes).

To increase the maximum possible bit rate per cell as well as for the individual user,
HSPA was defined in Release 5 & 6 of 3GPP.

In High-Speed Downlink Packet Access (HSDPA) the High-Speed Downlink Shared

Channel (HS-DSCH) which bundles several High-Speed Physical Downlink Shared
Channels (HS-DSCHs) is used by several UEs simultaneously – that is why it is called a
shared channel.

A single UE using HSDPA works in the RRC CELL_DCH state. For DL payload transport
the HSDSCH is used, that is, ,mapped onto the HS-PDSCH.

The UL IP payload is still transferred using a dedicated physical data channel (and
appropriate Iub transport bearer): in addition, the RRC signalling is exchanged
between the UE and RNC using the dedicated channels as shown in the diagram
above.

21
All these channels have to be setup and (re) configured during a call. In all these cases
both parties of the radio connection, cell and UE, have to be informed about the
required changes.

While communication between the NodeB (cell) and CRNC (Controlling RNC) uses
NBAP (Node B Application Part) the connection between the UE and the SRNC
(physically the same unit, but different protocol) uses the RRC protocol.

The big advantage of using a shared channel is higher efficiency in the usage of the
available radio resources.

There is no limitation due to the availability of codes and the individual data rate
assigned to a UE can be adjusted quicker to the real needs.

The only limitation is the availability of processing resources (represented by channel

card elements) and buffer memory in the base station.

In 3G networks the benefits of an Uplink Shared Channel (UL-SCH) have not yet been
introduced due to the need for UL power control, that is, a basic constraint of
Wideband CDMA networks.

Hence, the UL channel used for High-Speed Uplink Packet Access (HSUPA) now
commonly called Enhanced Uplink, is an Enhanced Dedicated Channel (E-DCH)).

The UL transmission data volume that can be transmitted by the UE on the UL is

controlled by using so-called “grants” to prevent buffer overflow in the base station
and RNC. The same “grant” mechanism will be found in LTE.

22
23
Hence from the user plane QoS perspective the two major targets of LTE are:
 A further increase in the available bandwidth and maximum data rate per
cell as well as for the individual subscriber
 Reducing the delays and interruptions in user data transfer to minimum

These are the reasons LTE has an always on concept in which the radio bearer is setup
immediately when a subscriber is attached to the network.

And all radio resources provided to subscribers by the E-UTRAN are shared resources
as shown overleaf.

24
The diagram above shows that the IP payload as well as the RRC and NAS signalling
are transmitted on the radio interfaces using unidirectional shared channels, the UL-
SCH and the Downlink Shared Channel (DL-SCH).

The payload part of this radio connection is called the radio bearer. The radio bearer
is the bidirectional point-to-point connection for the user plane between the UE nd
the eNodeB (eNB)

The RAB is the user plane connection between the UE and the Serving Gateway (S-
GW) and the S5 bearer is the user plane connection between the S-GW and public
data network gateway (PDN-GW).

The end-to-end connection between the UE and PDN-GW, that is, the gateway to the
IP world outside the operator’s network, is called a PDN connection in the E-UTRAN
standard documents and a session in the core network standards.

Regardless, the main characteristics of this PDN connection is that the IP payload is
transparently tunnelled through the core and the radio access network.

To control the tunnels and radio resources a set of control plane connections run in
parallel with the payload transport.

25
On the radio interface RRC and NAS signalling messages are transmitted using the
same shared channels and the same RLC transport layer that is used to transport the
IP payload.

26
27
28
29
Hand-in-hand with the 3GPP System Architecture Evolution work, the work on the
next generation RAN was carried out in the LTE study.

Just like the outcome of the SAE work was specifications of EPC, the outcome of the
LTE was specifications of E-UTRAN, short for Evolved – UTRAN.

A summary of the most important targets include:

• Downlink and uplink peak rate data rates of at least 100 and 50 Mbits/s
respectively, assuming that a 20MHz wide spectrum is used
• The time it takes to change a user device from idle to active state shall not be more
than 100ms
• The latency (delay) of user data shall not be more than 5ms in the radio access
network
• Spectrum efficiency of 2-4x compared to a Rel-6 3G network where spectrum
efficiency was measured as cell throughput in bits/s/MHz
• Interruption time during handover from LTE to GSM or WCDMA of maximum 300
or 500ms for non-real-time and real-time services respectively
• Support for both FDD and TDD multiplexing schemes with the same radio access
technology
• Support for a wide range of channel bandwidths, ranging from 1.4MHz to 20 MHz

30
The S1 interface is divided into two parts:
1. S1-MME carries signalling messages between the base station and the MME. In
addition it also carries signalling messages between the terminal and the MME
which are relayed via the base station and piggybacked on radio interface
signalling over the air interface.
2. S1-U interface carried user data between the base station and the Serving GW

31
In this type of architecture the 3GPP have tried to offer full transparency to network
connections and have offered both physical and logical connectivity.

In essence different functions may be implemented in software and connect with one
another via an internal interface, rather than via an actual cable. Also the physical
implementation of a particular interface may not run directly between two nodes; it
may be routed via another physical site.

Naturally interfaces may also share transmission links.

One example is that of the X2 interface connecting two eNodeBs which may
physically be routed from eNodeB A together with S1 interface (which connects an
eNodeB to an MME in the core network) to a site in the network with core network
equipment. From this site it would be routed back onto the radio access and finally to
eNodeB B. this is shown above.

32
33
34
35
36
37
38
39
The IMSI allows unambiguous identification of a particular SIM or USIM card. The
IMSI is composed of three parts as shown above.

 The Mobile Country Code (MCC) consisting of three digits. The MCC
uniquely identifies the country of domicile of the mobile subscriber. MCC
values are administered by an international numbering plan

 The Mobile Network Code (MNC), consisting of two or three digits for
GSM/UMTS applications. The MNC identifies the home PLMN of the mobile
subscriber. The length of the MNC (two or three digits) depends on the
value of the MCC. A mixture of two- and three-digit MNC codes within a
single MCC area is not recommended

 The Mobile Subscriber Identification Number (MSIN), identifying the

mobile subscriber within a PLMN. As a rule the first two or three digits of
the MSIN reveal the identity of the Home Location Register (HLR) or HSS
that is used for Signalling Connection Control Part (SCCP) Global Title
Translation procedures when roaming subscribers register in foreign
networks

40
41
Temporary subscriber identifier are used for several purposes. They provide a level of
privacy since permanent identity does not need to be sent over the radio interface.
But more importantly they provide a mechanism to find the resources where the
subscriber’s temporary context is stored. The temporary context for the subscriber is
stored in the MME (or SGSN in the 2G/3G case) and for example the eNodeB needs to
be able to send signalling from the UE to the correct MME where the Subscriber’s
context resides. Pooling MMEs was an integral part of the SAE/LTE design. Hence the
temporary identifiers.
The diagram above shows the temporary identities. The GUTI (Globally Unique
Temporary ID) is a worldwide unique identity that points to a specific subscriber
context in a specific MME. The S-TMSI is unique within a particular area of a single
network. The UE can use the S-TMSI when communicating with the network as long
as it stays within a TA that is part of the TA list it has received.
The GUTI consists of two main components. (1) the GUMMEI (Globally Unique MME
Identifier) that uniquely identifies the MME which allocated the GUTI and (2) the M-
TMSI (MME Temporary Subscriber Identity) that identifies the subscriber within the
MME
The GUMMEI is in turn made up of the MCC, MNC and MMEI (MME identifier, the
MME within the network). The MMEI is constructed from an MMEGI (MME group ID)
and MMEC (MME Code).
The S-TMSI is constructed from the MMEC and the M-TMSI as used instead of the
longer GUTI where possible.

42
43
The EPS bearer service layered architecture is shown above. Besides the different
names of the bearers and reference points, this architecture does not look very
different from the bearer service architecture of Release 99. however there is a major
difference that is not obvious at first sight.

In 3G UMTS the request of a subscriber for a defined QoS of an end-to-end service

starts the QoS negotiation procedure.

This depends on the subscriber’s subscribed QoS stored in the HLR and the available
network resources which QoS is granted to a particular connection at the end.

The QoS negotiation and control process starts on the NAS layer with the first SM
message sent by the UE.

In LTE – different to 2.5 and 3G PS connections – a default bearer with a default QoS is
already established when the UE attaches to the network.

The QoS attributes of this default bearer are determined by the subscribed QoS
parameters stored in the HSS. This is still as seen in 2.5/3G networks.

However if now the first user plane packet is sent by the UE , it is routed toward the
PDN where the PCRF analyses the requested end-to-end service.

44
Depending on the service, the PCRF may now trigger a modification of QoS
parameters in all the involved bearers. There is no option for the subscriber to
request a particular QoS; only the network is in charge of QoS control.

There is also no way for the UE to request something known as a secondary context
in 3G.

In LTE all QoS management is tied to the application, not to SM signalling. It is

important to understand that one UE in LTE can have multiple end-to-end services
active and each of these services will have its own individual bearer.

It is not intended by LTE standards that, for example, non real-time services like web-
browsing and e-mail will be mapped onto the same bearer (e.g., the same S1-U GTP
tunnel) as we have seen in 3G UMTS.

For this reason also 256 individual E-RABS for a single UE can be addressed by E-
UTRAN protocols while in UMTS only 15 different RAB-IDs had been defined by the
standard organisations.

45
In the 3GPP specs there is also a Traffic Flow Template (TFT) mentioned for UL as well
as for the DL part of the connection.

These TFTs are bound to the EPS bearers. In general, a TFT can be described as a set
of filters for a particular end-to-end service.

Each TFT consists of a destination IP address and a set of source/destination port

numbers.

On the DL, the IP address is the address of the assigned UE; on the UL, it I the address
of the PDN.

If we assume, for example, an HTTP 1.1 end-to-end service, the DL TFT of this service
consists of the UE’s IP address, the TCP source port number, 80 and the TCP
destination port number 80.

On the UL, the port numbers are the same, but the IP address is the address of the
server that hosts the web site.

To standardise the QoS handling, a set of nine QCIs have been defined by 3GPP. There
are four classes with a Guaranteed Bit Rate (GBR) and five classes with a Non-
Guaranteed Bit Rate (Non-GBR). Besides the bit rate, the parameter priority, packet
delay budget and packet error loss rate are also critical factors.

46
47
Some aspects of the user plane handling of EPS bearers were introduced already, in
particular it was here shown how packet filters in the UE and the GW are used to
determine which IP flows shall be carried over a certain EPS bearer.

The diagram above shows how different QoS parameters present on EPS bearers are
handled and which ones are present in different areas of the EPS network.

48
PCC provides the network operator with tools for service-aware QoS and charging
control. In wireless networks, where the bandwidth is typically limited by the radio
network, it is important to ensure an efficient utilisation of the radio and transport
network resources. Furthermore different services have very different requirements
on the QoS, which are needed for packet transport. Since a network in general carries
many different services for different users simultaneously, it is important to ensure
that the services can co-exist and that each service is provided with an appropriate
transport path.

49
50
51
Once the service session is set up and the media traffic for the service is flowing the
PCEF and the BBERF use the packet filters of the installed PCC and QoS rules to
classify IP Packets to authorised SDFs. This process is referred to as SDF detection.

Each filter in the SDF filter is associated with a precedence value. The PCEF (or BBERF)
matches the incoming packets against the available filters of the installed rules on
order of precedence. The precedence is important if there is an overlap between
filters in different PCC rules.

One example is a rule which contains a wildcard filter that overlaps with more
narrowly scoped filters in other PCC rules.

In this case the wildcard filter should be evaluated after the more narrowly scoped
filter; otherwise the wildcard filter will cause a match before the PCEF/BBERF even
tries the narrowly scoped filters. If the packet matches a filter and the gate of the
associated rule I open, then the packet may be forwarded to its destination.

For the downlink part the classification of an IP packet to an SDF also determines
which bearer should be used to transfer the packet, see the diagram above

52
An additional aspect related to SDF detection occurs when DSMIPv6 is used as a
mobility protocol. In that case the user plane traffic is tunnelled between UE and PDN
GW and thus also when passing through the BBERF. Since the packet filters of the PCC
rule refer to un-tunnelled packet flows, the BBERF has to ‘look inside’, the DSMIPv6
tunnel to be able to apply packet filters in the SDF template.

This is something often referred to as ‘tunnel look-through’ and is illustrated above.

The outer tunnel header is determined when the DSMIPv6 tunnel is established by
the UE and the PDN GW. Information about the tunnel header that is, the outer
header IP addresses, etc., is sent from the PDN GW to the BBERF via the PCRF so that
the BBERF can apply the right packet filters for the tunnel.

53
The diagram above shows a high level view of information transfer for both off path
and on path PCC architecture.

54
Most functions of the PCEF are common to both on-path and off-path models. For
example, service level charging, gate control, QoS enforcement and event reporting
are done in the PCEF in both cases. However, as we have also seen the bearer-related
functions and certain event reporting need to be performed by the BBERF in the off-
path case. The table above summarises the allocation of different function in the two
architecture alternatives.

55
Between the core network nodes in EPC the user plane traffic belonging to a bearer is
transported using an encapsulation header (tunnel header) that identifies the bearer.
The encapsulation protocol is GTP-U. when E-UTRAN is used, GTP-U is used on S1-U
and can also be used on S5/S8.

The GTP-U header contains a filed that allows the receiving node to identify the
bearer the packet belongs to, the diagram above illustrates two EPS bearers in a GTP-
based system.

56
It was decided in 2007 that the PMIP-based reference points would not be aware of
the EPS bearers. This means that it is not possible for the bearers to extend all the
way between UE and PDN GW. Instead the bearers are only defined between the UE
and Serving GW when PMIP-based S5/S8 is used.

Consequently, it ia not sufficient to have packet filters only in the UE and PDN GW.
Without bearer marking between the S-GW and PDN GE, also the Serving GW would
need to know the packet filters in order to map downlik traffic onto appropriate
bearer towards the UE

57
58
A new scheduling assignment is transmitted for each subframe, thus the scheduling
period on the time axis is 1 ms

The DL scheduling information is transmitted in the PDCCH. The assignments on the

frequency scale vary between one RB (minimal scheduled transmission) and the
maximum number of available RBs in respect of the system bandwidth.

Generally, LTE scheduling algorithm is not defined by the standard, it is a matter for
the eNB vendors. This enables the base station vendors to differentiate between each
other and use different optimisation goals.

Various parameters can be used as input for the scheduling decisions; channel quality
of different users (measured or reported by the UE with Channel Quality Indicator,
CQI), QoS, congestion/resource situation, fairness, charging policies and so on.

Most schedulers aim to maimise the cell throughput under consideration of fairness
metrics between cell edge users and users with very good channel conditions.

59
 DCI format 0: UL scheduling grant

 DCI format 1: single transport block (code word) scheduling assignment, for
example, used for assigning resources to system information, paging, or random
access. Also: MCS, HARQ (New Data Indicator (NDI), redundancy version, HARQ
process number) and TPC for PUCCH

 DCI format 1A: Compact single transport block scheduling assignment. MCS, HARQ
(New Data Indicator (NDI), redundancy version, HARQ process number) and TPC
for PUCCH

 DCI format 1B: A special DCI format for transmission mode 6 (MIMO closed loop
rank 1 precoding). Precoding vector, MCS, HARQ (New Data Indicator (NDI),
redundancy version, HARQ process number) and TPC for PUCCH

 DCI format 1C: Even more compact scheduling format as DCI 1A. For example used
for assigning resources to SIBs, paging, or RARs. This DCI is always transmitted
using frequency diversity via distributed virtual resource allocation type 2. this is
done because channel feedback cannot be derived for such common information,
as it is received by multiple users. The modulation is fixed to QPSK. MCS, HARQ
(New Data Indicator (NDI), redundancy version, HARQ process number) and TPC
for PUCCH

60
DCI format 1D: A special DCI format for transmission mode 5 (Multi-user MIMO)

DCI format 2: Scheduling for transmission mode 4 (closed loop MIMO), multiple
antenna port transmission operation, addressing multiple transport blocks (code
words) to be transmitted on different antenna ports (layers).

DCI format 2A: Used with transmission mode 3 (open loop MIMO using Cyclic Delay
Diversity (CDD)), multiple antenna port transmission operation, addressing multiple
transport blocks (code words) to be transmitted on different antenna ports (layers)

DCI format 3: A 2-bit UL TPC command applying for PUSCH and PUCCH. Multiple users
are addressed

DCI format 3A: a 1-bit UL TPC command applying for PUSCH and PUCCH. Multiple
users are addressed

61
62
63
A UE is in the ECM-IDLE state when no active NAS signalling connection between the
UE and MME exists. In other words, there are no SRBs assigned to this mobile. If the
UE changes its geographic location it may perform cell selection/reselection when
necessary.

The UE and the MME enter the ECM-CONNECTED state whenever the UE sends or
MME receives one of the following NAS messages:

 Attach Request
 Tracking Area Update Request
 Service Request
 Detach request

When the UE is in the ECM-IDLE state it is possible that the UE and the network have
different sets of established EPS bearers stored in their system memory.

When the UE and MME enter the ECM-CONNECTED state, the set of EPS bearers is
synchronised between the UE and the network.

64
ECM state and EMM state do not strictly depend on each other. For instance a UE can
be in ECM-IDLE but EMM_REGISTERED. However, a UE can also be in ECM-
CONNECTED while in EMM_DERGISTERED, yet it happens during the radio connection
for initial registration.

Firstly, the UE must enter ECM-CONNECTED to send Attach Request and only if Attach
Accept is sent back by the network does this UE enter EMM-REGISTERED

65
66
67
Once the relation between the eNB and MME is successfully established, UEs
camping on the cells of this eNB can be paged suing S1AP to establish mobile
terminating connections or register and setup mobile originating calls by themselves.

In the case of such a registration of connection setup procedure, the S1AP provides
functions for transparent forwarding of NAS messages.

During connection setup the S1AP is in charge of the tunnel management of S1-U GTP
tunnels.

Using the S1AP signalling procedure, these S1 user plane tunnels can be established,
modified according to changing QoS parameters and released.

The S1-U GTP tunnels are part of the E-RABs and in fact it is the S1AP that provides
full E-RAB management functions.

Setup and modification of E-RABs are always triggered by the MME, while the release
of E-RABs can be triggered by both the MME and eNB

68
These connection identifiers link all S1AP messages belonging to a single subscriber
except paging messages (i.e., sent before the UE context is established).

The following tables show the occurrences of the UE S1AP IDs in the different UE-
related messages of this protocol.

69
S1AP UE IDs in UE Related Messages

70
S1AP Class 1 elementary procedures

71
S1AP Class 2 elementary procedures

72
73
74
1. The UE initiates the Attach procedure by the transmission, to the eNodeB, of an Attach
Request (IMSI or old GUTI, last visited TAI (if available), UE Core Network Capability, UE
Specific DRX parameters, Attach Type, ESM message container (Request Type, PDN Type,
Protocol Configuration Options, Ciphered Options Transfer Flag), KSIASME, NAS sequence
number, NAS-MAC, additional GUTI, P-TMSI signature) message together with RRC
parameters indicating the Selected Network and the old GUMMEI.

The old GUTI may be derived from a P-TMSI and RAI. IMSI shall be included if the UE does not
have a valid GUTI or a valid P-TMSI available.

The UE stores the TIN in detached state. If the UE's TIN indicates "GUTI" or "RAT-related
TMSI" and the UE holds a valid GUTI then the old GUTI indicates this valid GUTI.

If the UE's TIN indicates "P-TMSI" and the UE holds a valid P-TMSI and related RAI then these
two elements are indicated as the old GUTI.

Mapping a P-TMSI and RAI to a GUTI is specified in TS 23.003 [9]. If the UE holds a valid GUTI
and the old GUTI indicates a GUTI mapped from a P-TMSI and RAI, then the UE indicates the
GUTI as additional GUTI.

If the old GUTI indicates a GUTI mapped from a P-TMSI and RAI and the UE has a valid P-TMSI
signature associated to it, the P-TMSI signature shall be included.

75
If available, the last visited TAI shall be included in order to help the MME produce a
good list of TAIs for any subsequent Attach Accept message. Selected Network
indicates the PLMN that is selected for network sharing purposes.

The RRC parameter "old GUMMEI" takes its value from the "old GUTI" contained in
the Attach Request. UE Network Capability is described in UE capabilities, see clause
5.11.

If the UE has valid security parameters, the Attach Request message shall be integrity
protected by the NAS-MAC in order to allow validation of the UE by the MME.

KSIASME, NAS sequence number and NAS-MAC are included if the UE has valid EPS
security parameters. NAS sequence number indicates the sequential number of the
NAS message.

If the UE does not have a valid EPS security association, then the Attach Request
message is not integrity protected. In this case the security association is established
in step 5a.
The UE network capabilities indicate also the supported NAS and AS security
algorithms. PDN type indicates the requested IP version (IPv4, IPv4/IPv6, IPv6).

Protocol Configuration Options (PCO) are used to transfer parameters between the
UE and the PDN GW, and are sent transparently through the MME and the Serving
GW.

76
77
The Protocol Configuration Options may include the Address Allocation Preference
indicating that the UE prefers to obtain an IPv4 address only after the default bearer
activation by means of DHCPv4. If the UE intends to send PCO which require ciphering
(e.g., PAP/CHAP usernames and passwords) or send an APN, or both, the UE shall set
the Ciphered Options Transfer Flag and send PCO or APN or both only after
authentication and NAS security setup have been completed (see below).

If the UE has UTRAN or GERAN capabilities, it should send the NRSU in the PCO to
indicate the support of the network requested bearer control in UTRAN/GERAN.

Request Type is included in the ESM message container and indicates "Handover"
when the UE has already an activated PDN GW/HA due to mobility with non-3GPP
accesses.

Attach Type indicates whether it is an EPS or a combined EPS/IMSI attach.

2. The eNodeB derives the MME from the RRC parameters carrying the old GUMMEI
and the indicated Selected Network.

If that MME is not associated with the eNodeB or the old GUMMEI is not available,
the eNodeB selects an MME as described in clause 4.3.8.3 on "MME selection
function".

The eNodeB forwards the Attach Request message to the new MME contained in a
S1-MME control message (Initial UE message) together with the Selected Network
and TAI+ECGI of the cell from where it received the message to the new MME.

3. If the UE identifies itself with GUTI and the MME has changed since detach, the
new MME uses the GUTI received from the UE to derive the old MME/SGSN address,
and send an Identification Request (old GUTI, complete Attach Request message) to
the old MME/SGSN to request the IMSI.

If the request is sent to an old MME, the old MME first verifies the Attach Request
message by NAS MAC and then responds with Identification Response (MM Context).
If the request is sent to an old SGSN, the old SGSN first verifies the Attach Request
message by the P-TMSI signature and then responds with Identification Response
(MM Context).

If the UE is not known in the old MME/SGSN or if the integrity check or P-TMSI
signature check for the Attach Request message fails, the old MME/SGSN responds
with an appropriate error cause.

The MM context contains security related information (as well as IMSI) as described
in clause 5.7.2 (Information Storage for MME).

78
The additional GUTI in the Attach Request message allows the new MME to find any
already existing UE context stored in the new MME when the old GUTI indicates a
value mapped from a P-TMSI and RAI.

NOTE 6: A SGSN always responds with the UMTS security parameters and the MME
may store it for later use.

4. If the UE is unknown in both the old MME/SGSN and new MME, the new MME
sends an Identity Request to the UE to request the IMSI. The UE responds with
Identity Response (IMSI).

5a If no UE context for the UE exists anywhere in the network, if the Attach Request
(sent in step 1) was not integrity protected, or if the check of the integrity failed, then
authentication and NAS security setup to activate integrity protection and NAS
ciphering are mandatory.

Otherwise it is optional. If NAS security algorithm is to be changed, the NAS security

setup is performed in this step.

The authentication and NAS security setup functions are defined in clause 5.3.10 on
"Security Function".

After step 5a, all NAS messages shall be protected by the NAS security functions
(integrity and ciphering) indicated by the MME.

5b. The ME Identity shall be retrieved from the UE. The ME identity shall be
transferred encrypted. In order to minimise signalling delays, the retrieval of the ME
Identity may be combined with NAS security setup in step 5a.

The MME may send the ME Identity Check Request (ME Identity, IMSI) to the EIR. The
EIR shall respond with ME Identity Check Ack (Result). Dependent upon the Result,
the MME decides whether to continue with this Attach procedure or to reject the UE.

6. If the UE has set the Ciphered Options Transfer Flag in the Attach Request message,
the Ciphered Options i.e. PCO or APN or both, shall now be retrieved from the UE.
In order to handle situations where the UE may have subscriptions to multiple PDNs,
if the Protocol Configuration Options contains user credentials (e.g. user
name/password within PAP or CHAP parameters) then the UE should also send the
APN to the MME.

7. If there are active bearer contexts in the new MME for this particular UE (i.e. the
UE re-attaches to the same MME without having properly detached before), the new
MME deletes these bearer contexts by sending Delete Session Request (TEIDs)
messages to the GWs involved.

The GWs acknowledge with Delete Session Response (TEIDs) message.

79
If a PCRF is deployed, the PDN GW employs an IP-CAN Session Termination procedure
to indicate that resources have been released.

8. If the MME has changed since the last detach, or if there is no valid subscription
context for the UE in the MME, or if the ME identity has changed, or if the UE
provides an IMSI or the UE provides an old GUTI which doesn't refer to a valid context
in the MME, the MME sends an Update Location Request (MME Identity, IMSI, ME
Identity, MME Capabilities, ULR-Flags) message to the HSS.

The MME capabilities indicate the MME's support for regional access restrictions
functionality. ULR-Flags indicates "Initial-Attach-Indicator" as this is an Attach
procedure.

9. The HSS sends Cancel Location (IMSI, Cancellation Type) to the old MME. The old
MME acknowledges with Cancel Location Ack (IMSI) and removes the MM and bearer
contexts.

If the ULR-Flags indicates "Initial-Attach-Indicator" and the HSS has the SGSN
registration, then the HSS sends Cancel Location (IMSI, Cancellation Type) to the old
SGSN.

The Cancellation Type indicates the old MME/SGSN to release the old Serving GW
resource

10. If there are active bearer contexts in the old MME/SGSN for this particular UE, the
old MME/SGSN deletes these bearer contexts by sending Delete Session Request
(TEIDs) messages to the GWs involved.

The GWs return Delete Session Response (TEIDs) message to the old MME/SGSN. If a
PCRF is deployed, the PDN GW employs an IP-CAN Session Termination procedure as
defined in TS 23.203 [6] to indicate that resources have been released.

11. The HSS acknowledges the Update Location message by sending an Update
Location Ack (IMSI, Subscription data) message to the new MME.

The Subscription Data contain one or more PDN subscription contexts. Each PDN
subscription context contains an 'EPS subscribed QoS profile' and the subscribed APN-
AMBR (see clause 4.7.3).

The new MME validates the UE's presence in the (new) TA. If due to regional
subscription restrictions or access restrictions the UE is not allowed to attach in the
TA or due to subscription checking fails for other reasons, the new MME rejects the
Attach Request with an appropriate cause.

If all checks are successful then the new MME constructs a context for the UE.

80
If the APN provided by the UE is not allowed by subscription, or the Update Location
is rejected by the HSS, the new MME rejects the Attach Request from the UE with an
appropriate cause.

12. If a subscribed PDN address is allocated for the UE for this APN, the PDN
subscription context contains the UE's IPv4 address and/or the IPv6 prefix and
optionally the PDN GW identity.

If the PDN subscription context contains a subscribed IPv4 address and/or IPv6 prefix,
the MME indicates it in the PDN address. For Request Type indicating "Initial
Request", if the UE does not provide an APN, the MME shall use the PDN GW
corresponding to the default APN for default bearer activation.

If the UE provides an APN, this APN shall be employed for default bearer activation.
For Request type indicating "Handover", if the UE provides an APN, the MME shall use
the PDN GW corresponding to the provided APN for default bearer activation, If the
UE does not provide an APN, and the subscription context from HSS contains a PDN
GW identity corresponding to the default APN, the MME shall use the PDN GW
corresponding to the default APN for default bearer activation.

The case where the Request type indicates "Handover" and the UE does not provide
an APN, and the subscription context from HSS does not contain a PDN GW identity
corresponding to the default APN constitutes an error case.

If the Request type indicates "Initial Request" and the selected PDN subscription
context contains no PDN GW identity the new MME selects a PDN GW as described in
clause 4.3.8.1 on PDN GW selection function (3GPP accesses).

If the PDN subscription context contains a dynamically allocated PDN GW identity and
the Request Type does not indicate "Handover" the MME may select a new PDN GW
as described in clause PDN GW selection function, e.g. to allocate a PDN GW that
allows for more efficient routing.

The new MME selects a Serving GW as described in clause 4.3.8.2 on Serving GW

selection function and allocates an EPS Bearer Identity for the Default Bearer
associated with the UE.

Then it sends a Create Session Request (IMSI, MSISDN, MME TEID for control plane,
PDN GW address, PDN Address, APN, RAT type, Default EPS Bearer QoS, PDN Type,
APN-AMBR, EPS Bearer Identity, Protocol Configuration Options, Handover Indication,
ME Identity, User Location Information (ECGI), MS Info Change Reporting support
indication, Selection Mode, Charging Characteristics, Trace Reference, Trace Type,
Trigger Id, OMC Identity, Maximum APN Restriction, Dual Address Bearer Flag, the
Protocol Type over S5/S8) message to the selected Serving GW.

The RAT type is provided in this message for the later PCC decision. The subscribed
APN-AMBR for the APN is also provided in this message.

81
The MSISDN is included if provided in the subscription data from the HSS. Handover
Indication is included if the Request type indicates handover. Selection Mode
indicates whether a subscribed APN was selected, or a non-subscribed APN sent by
the UE was selected.

Charging Characteristics indicates which kind of charging the bearer context is liable
for. The MME may change the requested PDN type according to the subscription data
for this APN as described in clause 5.3.1.1.

The MME shall set the Dual Address Bearer Flag when the PDN type is set to IPv4v6
and all SGSNs which the UE may be handed over to are Release 8 or above supporting
dual addressing, which is determined based on node pre-configuration by the
operator.

The Protocol Type over S5/S8 is provided to Serving GW which protocol should be
used over S5/S8 interface.

The charging characteristics for the PS subscription and individually subscribed APNs
as well as the way of handling Charging Characteristics and whether to send them or
not to the P-GW is defined in TS 32.251 [44].

The MME shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity if S-
GW and/or P-GW trace is activated.

The MME shall copy Trace Reference, Trace Type, and OMC Identity from the trace
information received from the HLR or OMC.

The Maximum APN Restriction denotes the most stringent restriction as required by
any already active bearer context. If there are no already active bearer contexts, this
value is set to the least restrictive type (see clause 15.4 of TS 23.060 [7]).

If the P-GW receives the Maximum APN Restriction, then the P-GW shall check if the
Maximum APN Restriction value does not conflict with the APN Restriction value
associated with this bearer context request. If there is no conflict the request shall be
allowed, otherwise the request shall be rejected with sending an appropriate error
cause to the UE.

13. The Serving GW creates a new entry in its EPS Bearer table and sends a Create
Session Request (IMSI, MSISDN, APN, Serving GW Address for the user plane, Serving
GW TEID of the user plane, Serving GW TEID of the control plane, RAT type, Default
EPS Bearer QoS, PDN Type, PDN Address, subscribed APN-AMBR, EPS Bearer Identity,
Protocol Configuration Options, Handover Indication, ME Identity, User Location
Information (ECGI), MS Info Change Reporting support indication, Selection Mode,
Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity,
Maximum APN Restriction, Dual Address Bearer Flag) message to the PDN GW
indicated by the PDN GW address received in the previous step.

82
After this step, the Serving GW buffers any downlink packets it may receive from the
PDN GW without sending a Downlink Data Notification message to the MME until it
receives the Modify Bearer Request message in step 23 below. The MSISDN is
included if received from the MME.

14. If dynamic PCC is deployed and the Handover Indication is not present, the PDN
GW performs an IP-CAN Session Establishment procedure as defined in TS 23.203 [6],
and thereby obtains the default PCC rules for the UE. This may lead to the
establishment of a number of dedicated bearers following the procedures defined in
clause 5.4.1 in association with the establishment of the default bearer, which is
described in Annex F.
The IMSI, UE IP address, User Location Information (ECGI), Serving Network, RAT type,
APN-AMBR, Default EPS Bearer QoS are provided to the PCRF by the PDN GW if
received by the previous message.

The User Location Information is used for location based charging.

The PCRF may modify the APN-AMBR and the QoS parameters (QCI and ARP)
associated with the default bearer in the response to the PDN GW as defined in TS
23.203 [6].

NOTE 7: While the PDN GW/PCEF may be configured to activate predefined PCC rules
for the default bearer, the interaction with the PCRF is still required to provide e.g. the
UE IP address information to the PCRF.

NOTE 8: If the IP address is not available when the PDN GW performs the IP-CAN
Session Establishment procedure with the PCRF, the PDN GW initiates an IP-CAN
Session Modification procedure to inform the PCRF about an allocated IP address as
soon as the address is available.

In this version of the specification, this is applicable only to IPv4 address allocation.

If dynamic PCC is deployed and the Handover Indication is present, the PDN GW
executes a PCEF Initiated IP-CAN Session Modification procedure with the PCRF as
specified in TS 23.203 [6] to report the new IP-CAN type.

Depending on the active PCC rules, the establishment of dedicated bearers for the UE
may be required. The establishment of those bearers shall take place in combination
with the default bearer activation as described in Annex F.

This procedure can continue without waiting for a PCRF response. If changes to the
active PCC rules are required, the PCRF may provide them after the handover
procedure is finished.

In both cases (Handover Indication is present or not), if dynamic PCC is not deployed,
the PDN GW may apply local QoS policy.

83
This may lead to the establishment of a number of dedicated bearers for the UE
following the procedures defined in clause 5.4.1 in combination with the
establishment of the default bearer, which is described in Annex F.

15. The P-GW creates a new entry in its EPS bearer context table and generates a
Charging Id. The new entry allows the P-GW to route user plane PDUs between the S-
GW and the packet data network, and to start charging.

The way the P-GW handles Charging Characteristics that it may have received is
defined in TS 32.251 [44].

The PDN GW returns a Create Session Response (PDN GW Address for the user plane,
PDN GW TEID of the user plane, PDN GW TEID of the control plane, PDN Type, PDN
Address, EPS Bearer Identity, EPS Bearer QoS, Protocol Configuration Options,
Charging Id, Prohibit Payload Compression, APN Restriction, Cause, MS Info Change
Reporting Action (Start) (if the PDN GW decides to receive UE's location information
during the session), APN-AMBR) message to the Serving GW. The PDN GW takes into
account the received PDN type, the Dual Address Bearer Flag and the policies of
operator when the PDN GW selects the PDN type to be used as follows.

If the received PDN type is IPv4v6 and both IPv4 and IPv6 addressing is possible in the
PDN but the Dual Address Bearer Flag is not set, or only single IP version addressing
for this APN is possible in the PDN, the PDN GW selects a single IP version (either IPv4
or IPv6).

If the received PDN type is IPv4 or IPv6, the PDN GW uses the received PDN type if it
is supported in the PDN, otherwise an appropriate error cause will be returned.

The PDN GW allocates a PDN Address according to the selected PDN type. If the PDN
GW has selected a PDN type different from the received PDN Type, the PDN GW
indicates together with the PDN type IE a reason cause to the UE why the PDN type
has been modified, as described in clause 5.3.1.1. PDN Address may contain an IPv4
address for IPv4 and/or an IPv6 prefix and an Interface Identifier.

If the PDN has been configured by the operator so that the PDN addresses for the
requested APN shall be allocated by usage of DHCPv4 only, or if the PDN GW allows
the UE to use DHCPv4 for address allocation according to the Address Allocation
Preference received from the UE, the PDN Address shall be set to 0.0.0.0, indicating
that the IPv4 PDN address shall be negotiated by the UE with DHCPv4 after
completion of the Default Bearer Activation procedure.

For external PDN addressing for IPv6, the PDN GW obtains the IPv6 prefix from the
external PDN using either RADIUS or Diameter client function.

In the PDN Address field of the Create Session Response, the PDN GW includes the
Interface Identifier and IPv6 prefix.

84
The PDN GW sends Router Advertisement to the UE after default bearer
establishment with the IPv6 prefix information for all cases. If the PDN address is
contained in the Create Session Request, the PDN GW shall allocate the IPv4 address
and/or IPv6 prefix contained in the PDN address to the UE.

The IP address allocation details are described in clause 5.3.1 on "IP Address
Allocation". The PDN GW derives the BCM based on the NRSU and operator policy.
Protocol Configuration Options contains the BCM as well as optional PDN parameters
that the P-GW may transfer to the UE.

These optional PDN parameters may be requested by the UE, or may be sent
unsolicited by the P-GW. Protocol Configuration Options are sent transparently
through the MME.

When the Handover Indication is present, the PDN GW does not yet send downlink
packets to the S-GW; the downlink path is to be switched at step 23a.

16. If the MS Info Change Reporting Action (Start) is received for this bearer context,
then the S-GW shall store this for the bearer context and the S-GW shall report to
that P-GW whenever a UE's location change occurs that meets the P-GW request, as
described in clause 15.1.1a of TS 23.060 [7].

The Serving GW returns a Create Session Response (PDN Type, PDN Address, Serving
GW address for User Plane, Serving GW TEID for User Plane, Serving GW TEID for
control plane, EPS Bearer Identity, EPS Bearer QoS, PDN GW addresses and TEIDs
(GTP-based S5/S8) or GRE keys (PMIP-based S5/S8) at the PDN GW(s) for uplink
traffic, Protocol Configuration Options, Prohibit Payload Compression, APN
Restriction, Cause, MS Info Change Reporting Action (Start), APN-AMBR) message to
the new MME.

17. If an APN Restriction is received, then the MME shall store this value for the
Bearer Context and the MME shall check this received value with the stored value for
the Maximum APN Restriction to ensure there are no conflicts between values.

If the Bearer Context is accepted, the MME shall determine a (new) value for the
Maximum APN Restriction. If there is no previously stored value for Maximum APN
Restriction, then the Maximum APN Restriction shall be set to the value of the
received APN Restriction.

If the MS Info Change Reporting Action (Start) is received for this bearer context, then
the MME shall store this for the bearer context and the MME shall report whenever a
UE's location change occurs that meets the request, as described in clause 15.1.1a of
TS 23.060 [7].

The MME determines the UE AMBR to be used by the eNodeB based on the
subscribed UE-AMBR and the APN-AMBR for the default APN, see clause 4.7.3.

85
The new MME sends an Attach Accept (APN, GUTI, PDN Type, PDN Address, TAI List,
EPS Bearer Identity, Session Management Request, Protocol Configuration Options,
NAS sequence number, NAS-MAC, IMS Voice over PS session supported Indication)
message to the eNodeB. GUTI is included if the new MME allocates a new GUTI.

This message is contained in an S1_MME control message Initial Context Setup

Request. This S1 control message also includes the AS security context information for
the UE, the Handover Restriction List, the EPS Bearer QoS, the UE-AMBR, EPS Bearer
Identity, as well as the TEID at the Serving GW used for user plane and the address of
the Serving GW for user plane.

In the Attach Accept message, the MME does not include the IPv6 prefix within the
PDN Address. The MME includes the EPS Bearer QoS parameter QCI and APN-AMBR
into the Session Management Request. Furthermore, if the UE has UTRAN or GERAN
capabilities, the MME uses the EPS bearer QoS information to derive the
corresponding PDP context parameters QoS Negotiated (R99 QoS profile), Radio
Priority, Packet Flow Id and TI and includes them in the Session Management
Request. If the UE indicated in the UE Network Capability it does not support BSS
packet flow procedures, then the MME shall not include the Packet Flow Id.

Handover Restriction List is described in clause 4.3.5.7 "Mobility Restrictions". The

MME sets the IMS Voice over PS session supported Indication as described in clause
4.3.5.8.

If the MME or PDN GW has changed the PDN Type, an appropriate reason cause shall
be returned to the UE as described in clause 5.3.1.1.

18. The eNodeB sends the RRC Connection Reconfiguration message including the
EPS Radio Bearer Identity to the UE, and the Attach Accept message will be sent along
to the UE. The UE shall store the QoS Negotiated, Radio Priority, Packet Flow Id and
TI, which it received in the Session Management Request, for use when accessing via
GERAN or UTRAN.

The APN is provided to the UE to notify it of the APN for which the activated default
bearer is associated. For further details, see TS 36.331 [37].

The UE may provide EPS Bearer QoS parameters to the application handling the traffic
flow(s). The application usage of the EPS Bearer QoS is implementation dependent.

The UE shall not reject the RRC Connection Reconfiguration on the basis of the EPS
Bearer QoS parameters contained in the Session Management Request.

When receiving the Attach Accept message the UE shall set its TIN to "GUTI" as no ISR
Activated is indicated.

86
If the UE receives an IPv4 address set to 0.0.0.0, it may negotiate the IPv4 address
with DHCPv4 as specified in TS 29.061 [38]. If the UE receives an IPv6 interface
identifier, it may wait for the Router Advertisement from the network with the IPv6
prefix information or it may send a Router Solicitation if necessary.

NOTE 9: The IP address allocation details are described in clause 5.3.1 on "IP Address
Allocation".

19. The UE sends the RRC Connection Reconfiguration Complete message to the
eNodeB. For further details, see TS 36.331 [37].

20. The eNodeB sends the Initial Context Response message to the new MME. This
Initial Context Response message includes the TEID of the eNodeB and the address of
the eNodeB used for downlink traffic on the S1_U reference point.

21. The UE sends a Direct Transfer message to the eNodeB, which includes the Attach
Complete (EPS Bearer Identity, NAS sequence number, NAS-MAC) message.

22. The eNodeB forwards the Attach Complete message to the new MME in an Uplink
NAS Transport message.

After the Attach Accept message and once the UE has obtained a PDN Address, the
UE can then send uplink packets towards the eNodeB which will then be tunnelled to
the Serving GW and PDN GW.

If the UE requested for a dual address PDN type (IPv4v6) to a given APN and was
granted a single address PDN type (IPv4 or IPv6) by the network with a reason cause
indicating that only single IP version per PDN connection is allowed sent together
with the PDN type, the UE may request for the activation of a parallel PDN connection
to the same APN with a single address PDN type (IPv4 or IPv6) other than the one
already activated.

If the UE receives no reason cause in step 18 in response to an IPv4v6 PDN type and it
receives an IPv6 Interface Identifier apart from the IPv4 address or 0.0.0.0 in the PDN
Address field, it considers that the request for a dual address PDN was successful.

It can wait for the Router Advertisement from the network with the IPv6 prefix
information or it may send Router Solicitation if necessary.

23. Upon reception of both, the Initial Context Response message in step 21 and the
Attach Complete message in step 22, the new MME sends a Modify Bearer Request
(EPS Bearer Identity, eNodeB address, eNodeB TEID, Handover Indication) message to
the Serving GW.

87
23a. If the Handover Indication is included in step 23, the Serving GW sends a Modify
Bearer Request (Handover Indication) message to the PDN GW to prompt the PDN
GW to tunnel packets from non 3GPP IP access to 3GPP access system and
immediately start routing packets to the Serving GW for the default and any
dedicated EPS bearers established.

23b. The PDN GW acknowledges by sending Modify Bearer Response to the Serving
GW.

24. The Serving GW acknowledges by sending Modify Bearer Response (EPS Bearer
Identity) message to the new MME. The Serving GW can then send its buffered
downlink packets.

25. After the MME receives Modify Bearer Response (EPS Bearer Identity) message, if
Request type does not indicate handover and an EPS bearer was established and the
subscription data indicates that the user is allowed to perform handover to non-3GPP
accesses, and if the MME selected a PDN GW that is different from the PDN GW
identity which was indicated by the HSS in the PDN subscription context, the MME
shall send a Notify Request including the APN and PDN GW identity to the HSS for
mobility with non-3GPP accesses.

The message shall also include information that identifies the PLMN in which the PDN
GW is located.

26. The HSS stores the APN and PDN GW identity pair and sends a Notify Response to
the MME.

NOTE 10: For handover from non-3GPP access, the PDN GW initiates resource
allocation deactivation procedure in the trusted/untrusted non-3GPP IP access as
specified in TS 23.402 [2].

88
After the flood of addresses and identifiers, the diagram above shows a summary
overview of the involved network elements and identifiers for a particular UE
connection and how the signalling and user plane packets are routed through the
network.

For the signalling connection between the UE & MME the UE is now identified by its
GUTI. The GUTI is linked to the IMSI that we encountered during the location update
procedure on S6a between the MME and HSS, but also during the create session
procedure on S11 between the MME and S-GW and on S5 between the S-GW and
PDN-GW.

These GTP signalling connections for a single UE are now unambiguously marked by
the IP addresses of the involved network elements (for S-GW and PDN-GW the IP
addresses for control plane traffic) and on each interface by a pair of TEIDs for the
control plane.

The same statement is true for the user plane transport tunnels on S1-U and S5. On
S5 between S-GW and PDN-GW we can also see how the user plane is separated from
the control plane traffic by defining intelligent numbering plans.

Indeed, there is no standard document that requires different IP addresses for control
plane and user plane traffic in the core network, but from experience gathered in
numerous lab and field trials it can be postulated that this is a kind of de-facto
standard followed by all network equipment manufacturers.

89
The logical connection for one UE on the S1 control plane is embraced by the pair of
S1AP-IDs. On the radio interface the same function is provided by the Cell Radio
Network Temporary Identifier (C-RNTI) that is signalled on the Medium Access
Control (MAC) layer.

The C-RNTI is both valid for the user plane and control plane, but eNodeB acts like a
switch that sends the control plane traffic across one way to the MME and user plane
packets across another way directly to the S-GW.

90
Whenever it is required by the parameters of a QoS profile, a dedicated bearer will be
established in parallel to the default bearer. The call flow of this procedure with a
focus on the protocol layers messages and RAB identifier is shown above.

In the upper part of the diagram we see the S1AP Initial Context Setup combined with
the establishment of the default bearer (RAB-ID=5). This part is covered previously in
Initial Attach.

After the default bearer is active a new user plane connection with a QoS profile
different from the default one requires a dedicated bearer that will run in parallel
with the default bearer.

In the call flow example the request to create this dedicated bearer comes from the S-
GW. But it may well come from the PCRF via the Gx interface after interaction with,
for example, a web-server or IP Multimedia Subsystem (IMS).

A typical scenario would be when a user browses a web site using his default bearer
then choses a video and triggers the requirement for a change of QoS.

This is the reason why the S-GW (triggered by the PDN-GW) sends a new GTP create
bearer request message for RAB-ID=6.

The new Traffic Format Template (TFT) in this message contains a list of specific QoS
parameters according to the requirements from streaming video, for example.

91
In the end the setup of the dedicated bearer happens in a similar way as the earlier
setup of the default bearer. However the e-RAB-ID, the QoS profile of the new bearer
and the message names on S1AP and the NAS protocol layer are different, as shown
overleaf.

92
When the UE changes its geographic position, a handover is required. Ideally this
handover is executed using the X2 interface – as long a the UE does not leave the LTE
coverage area in general.

As shown above there are three major steps to be executed in the network for this
kind of handover. An additional step is a subsequently executed tracking area update
procedure after the UE is connected to the target cell. This tracking area update is not
shown above.

The three major steps are:

1. An X2 handover preparation procedure is executed on the X2 interface to connect
the source and the target eNB with each other. During this procedure a signalling
connection using the X2 Application Part (X2AP) is established as well as a
temporary user plane tunnel to forward user plane data from the source to the
target.
2. Using the S1AP path switch request procedure the target eNB updates the MME
with the new geographic position of the UE and requests a new route for GTP-U
tunnel on the S1-U interface
3. To enable this new route for user plane data on S1-UE the MME needs to
communicate with S-GW, basically to negotiate the new endpoints of the GTP-U
tunnel
The radio bearer also has to change and the UE must perform RRC reconfiguration
procedure and must enter the new cell using random access during handover, this is
new to LTE.

93
Step 1
Triggered by a RRC DL quality measurement result or by an internal UL quality
measurement result, the source eNB starts the X2 handover procedure by sending an
X2AP initiating message for handover request (3GPP message name: X2AP Handover
Request) to the target eNB.

The message contains the cause value related to the handover request (a typical one
is the radio network cause “handover desirable for radio reasons”), the cell-ID of the
source cell, the GUMMEI to identify the MME that manages mobility procedures for
this particular call, the MME-UE-S1AP-ID that is the unique identity of this call in the
MME S1AP protocol entity, e-RAB-ID and appropriate QoS parameters of this e-RAB
and an UL TEID value.

If there is more than just on e-RAB active for this radio connection, multiple e-RAB-
IDs and QoS parameter lists will be found in the X2AP message.

The UL TEID signalled in the X2AP initiating message for handover preparation is the
one currently assigned by S-GW for the IP tunnel on the S1-U reference point.

Furthermore, the message contains the RRC context of the radio connection that
includes, for example, all security parameters.

Also access stratum security information like the key-eNB is transmitted from the
source eNB to target eNB.

94
Step 2
The target eNB responds to the source eNB with an X2AP successful outcome
message for “Handover Preparation” (3GPP message name: X2AP Handover Request
Acknowledge), including the same e-RAB-ID9s) found previously in the initiating
message.

There is a UL TEID and a DL TEID together with the transport layer address of the
appropriate network element enclosed in this message.

These TEIDs will be used to forward unsent payload packets from the source to the
target eNB across X2 interface.

It must be emphasised that both the UL and DL TEIDs are assigned by the target eNB.
This is because the temporary GTP-U tunnel on the X2 reference point during
handover procedure is used as a unidirectional connection on which the all remaining
packets of the connection still stored in the source eNB’s buffer are forwarded to the
target eNB without any acknowledgement from the receiver side.

In case of packet loss, higher user plane layers like TCP have to order the necessary
retransmissions using end-to-end IP connection between the UE and application
server.

The reason why separate TEIDs for UL and DL are assigned by the target eNB is to
separate UL payload traffic that still needs to be sent to the S-GW from DL payload
traffic still needing to be sent to the UE across the radio interface.

The transparent container embedded in the X2AP handover request

acknowledgement message contains the radio resources, especially scheduling
information, initially assigned by the target cell to serve this particular radio
connection.

Step 3
The source eNB sends an X2AP initiating message for “SN Status Transfer” , including
the impacted e-RAB-ID(s) and Packet Data Convergence Protocol (PDCP) SNs for UL
and DL data transfer across the radio interface.

These PDCP SN count values are mandatory for a seamless continuation of ciphering
and integrity functions after successful handover.

Step 4
Now it is time to switch the S1-U GTP tunnel toward the target eNB. To request this
change in routing of payload packets, the target eNB sends a S1AP initiating message
for Path Switch Request to the MME.

It contains the new location of the UE represented by the target cell ID and the TAC of
the target cell.

95
The sourseMME-UE-S1AP-ID allows identification of the connection of the particular
handset unambiguously within the MME’s S1AP entity.

The DL GTP-U TEID is the TEID to be used for sending payload packets in the DL
direction on the S1-U interface after the path switch procedure has been successfully
completed.

Step 5
Since the GTP-U tunnel needs to be switched on the interface between eNB and S-
GW, the MME sends a GTP-C Update User Plane Request message to the S-GW that
contains the EBIs of the RABs to be switched and the S1-U eNB TEID for DL payload
transmission using the new tunnel as was sent by the target eNB to the MME in step
4.

Step 6
The S-GW returns a GTP-C Update User Plane Response message containing again EBI
and UL GTP-U TEID of the new tunnel. In this example the UL GTP-U TEID remains
unchanged. Thus, it has the same value as signalled with the X2AP handover request
message in step 1.

Step 7
After successful update user plane procedure on S11, the MME now sends the
successful outcome message of the S1AP path switch request procedure to the target
eNB.

This message confirms that the UL GTP-U TEID on S1-U will remain the same.

Step 8
An X2AP UE release request message is sent by the target eNB to the source eNB to
indicate the successful completed radio interface handover and path switching.

This p[articular UE connection is unambiguously identified by the pair of Old-eNB-UE-

X2AP-ID and New-eNB-UE-X2AP-ID. When receiving this message the source eNB will
release all UE-specific information and radio resources.

However, it may continue user plane data forwarding to the target eNB as long as this
is necessary.

Step 9
Although the inter-eNB handover is already successfully completed in the access
stratum at this point and payload data transfer using the new transport resources on
the radio interface and S1-U may have already started, it is still necessary to update
the UE location on the NAS layer.

This is only necessary if the target cell belongs to a different tracking area than the
source cell.

96
The TAC of the target cell is detected by the UE when reading the cell’s broadcast
information.

After detecting the new TAC, the UE sends the NAS tracking area update request
message to the MME. This message contains the new location of the UE (cell-ID of
the target cell) and new TAC, while in the NAS tracking area request message the old
GUTI identifying the UE on the NAS layer, the UE network capabilities and TAC of the
old cell (source cell) are also included.

Step 10
Responding to the UE’s Tracking Area Update Request, the MME sends a NAS Tracking
Area Update Accept back to the mobile.

If a new GUTI is assigned depending on the MME’s configuration parameters for

subscriber management, the new GUTI will be included in this message and the
handset will confirm reception of this new temporary identity with a TAC message,

97
98
99
The protocol stack used on the radio interface is shown above. The physical layer in
this stack is represented by OFDM in the DL and SC-FDMA in the UL.

Then we see the MAC protocol that is responsible for mapping the transport channels
onto the physical channels, but also for such important tasks as packet scheduling and
timing advance control.

RLC provides reliable transport services and can be used to segment/reassemble large
frames.

The main purpose of PDCP is the compression of larger IP headers as well as ciphering
of user plane data and integrity protection of both user plane and control plane data.

On top of PDCP the stack is split into the user plane and the control plane parts. On
the control plane side we see RRC protocol, that is, the expression for the
communication between the UE and eNB.

RRC provides all the necessary functions to set up, maintain and release a radio
connection for a particular subscriber.

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

On the user plane side we can see IP as the transport layer for end-to-end
applications. On the Uu stack the IP is always end-to-end IP, which means that all
these IP packets are transparently routed, often tunnelled through the mobile
network.

The user plane IP frames we see on Uu are the same IP frames that can be monitored
at SGi reference points before or behind the PDN-GW.

The IP version can be IPv4 or IPv6. in the case of VPN traffic, IPSec will be used.

The application on top of IP in the user plane stack are all protocols of the TCP/IP
suite, such as, Real-Time Transport Protocol (RTP) and SIP for real-time services like
VoIP.

101
On the S1 reference point the physical layer L1 will in most cases be realised by
Gigabit Ethernet cables. L2 in this case will be Ethernet.

On top of Ethernet we find IP, but used as a transport protocol between two network
nodes: eNB and MME. This lower layer IP does not represent the user plane frames.

Instead, the user plane IP frames (higher layer IP) are carried by the GTP Tunnelling
Packet Data Unit (T-PDU). The GTP is responsible for the transport of payload frames
through the IP tunnels on S1-U.

The transport layer for GTP-U is the User Datagram Protocol (UDP). As IP this protocol
may be found twice in the user plane stack: lower UDP for transport between eNB
and MME and higher UDP (not shown) that is transparently routed through the
mobile network as the transport protocol for real-time application data.

The higher layer IP on top of GTP-U as well as all application data on top of this higher
layer IP are identical with the user plane information described in the previous
section.

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

102
SCTP applications submit their data to be transmitted in messages (groups of bytes)
to the SCTP transport layer. SCTP places messages and control information into
separate chunks (data chunks and control chunks), each identified by a chunk header.
A message can be fragmented over a number of data chunks, but each data chunk
contains data from only one user message. SCTP chunks are bundled into SCTP
packets.
The SCTP packet, which is submitted to the Internet Protocol, consists of a packet
header, SCTP control chunks when necessary, followed by SCTP data chunks when
available.
SCTP may be characterized as message-oriented, meaning it transports a sequence of
messages (each being a group of bytes), rather than transporting an unbroken stream
of bytes as does the TCP Protocol.
As in the (UDP), in SCTP a sender sends a message in one operation, and that exact
message is passed by the receiving SCTP to the receiving application process in one
operation.
In contrast, TCP is stream-oriented protocol, transporting streams of bytes reliably
and in order.
However TCP does not allow the receiver to know how many times the sender
application called on the TCP transport passing it groups of bytes to be sent out.
The sender TCP effectively simply appends more bytes to a queue of bytes waiting to
go out over the network, rather than having to keep a queue of individual separate
outbound messages which must be preserved as such.

103
The term multi-streaming refers to the capability of SCTP to transmit several
independent streams of chunks in parallel, for example transmitting Web page images
together with the Web page text.
In essence, it is the bundling of several connections into a single SCTP association,
operating on messages (or chunks) rather than bytes.
TCP preserves byte order in the stream by assigning a sequence number to each
packet. SCTP, on the other hand, assigns a sequence number to each message sent in
a stream. This allows independent ordering of messages in different streams.
However, message ordering is optional in SCTP; a receiving application may choose to
process messages in the order they are received instead of the order they were sent.
Features of SCTP include:
Multihoming support in which one or both endpoints of a connection can consist of
more than one IP address, enabling transparent fail-over between redundant network
paths.
Delivery of chunks within independent streams eliminate unnecessary head-of-line
blocking, as opposed to TCP byte-stream delivery.
Path selection and monitoring select a primary data transmission path and test the
connectivity of the transmission path.
Validation and acknowledgment mechanisms protect against flooding attacks and
provide notification of duplicated or missing data chunks.
Improved error detection suitable for Ethernet jumbo frames.

104
On the X2 interface the user plane protocol stack is identical to that of the S1
interface point.

However as shown above on the control plane there is a different protocol X2

Application Part (X2-AP)

The main purpose of X2-AP is to provide inter-eNodeB handover functionality. It is

also used to exchange traffic-related and radio quality measurement reports between
different eNBs.

105
There is no user plane at the S6a reference point due the fact that we find here the
connection between MME and HSS, which is a plain signalling communication.

L1, L2, IP and SCTP shown above provide the same functionality as explained before
in S1.

The new player in the S6a stack is the Diameter protocol.

In the EPC network DIAMETER has taken over from Mobile Application Part (MAP). It
is used to update the HSS about the current location of the subscriber and to provide
crucial subscriber attributes stored in HSS databases to the MME so that network
access can be granted and the subscriber’s traffic can be routed according to these
parameters.

DIAMETER is also involved in the security functions of the network; subscriber

authentication, integrity protection and ciphering.

The protocol stack of S6a is identical to the protocol stack of S13 reference point
between the MME and EIR – in case an EIR exists in the network.

106
At the S3, S4, S5, S8, S10 and S11 reference points we find the same protocol stack as
shown above.

The reason is that all these interfaces are used to tunnel IP payload transparently
from one network node to the other.

The tunnel management is provided by GTP-C while the IP payload is transported

using GTP-U T-PDUs.

Indeed the user plane protocol stack is the same as on the S1 reference point.

Simplifying the functionality of GTP-C, it can be said that this protocol is used to
create, modify and delete user plane tunnels. It also supports mobility of subscribers
between core network nodes.

107
According to 3GPP, Layer 2 structure consists of PDCP/RLC/MAC layers. Transport
channels are located between physical layer and MAC layer. MAC multiplexes RLC
links and scheduling and priority handling serving via logical channels. Layer 2
downlink and uplink structures are shown above and overleaf.

LTE splits the layer 2 into three sublayers: MAC layer, RLC layer and PDCP layer.

The sublayers communicate via Service Access Points (SAPSs). A lower layer provides
services to the adjacent layer above through SAPs.

From the point of view of the lower layer, the packets prroviding this service are
Service Data Units (SDUs). This layer once more uses services from a lower layer,
again by giving its packets through SAPs to the adjacent lower layer.

Those packets are called Packet Data Units (PDUs). Hence a PDU from a higher layer is
a SDUN from the point of view of the lower layer providing a service to a higher layer.

Each layer with its unique functionality is introduced in the next few sections.

108
Medium Access Control (MAC, provides services through SAPs to the upper layer as
all other sublayers of layer 2.

The layer above MAC is the RLC layer; the lower layer is the physical layer which
provides services to the MAC layer.

In the case of the MAC, SAPs to the RLC layer are logical channels. Logical channels
are used by higher layers to differentiate between logical connections which may use
different metrics, for example, in terms of quality or delay, and so on.

Furthermore logical channels are used to distinguish control plane connections, either
CCCHs or DCCHs, from user plane connections (DTCHs).

Services provided by the physical layer to the MAC are granted via another type of
SAP. SAPs between MAC and the physical layer are transport channels.

Transport channels match data units to physical channels in which data is supposed to
be transmitted. One exception is the PCH which is multiplexed into the PDSCH
identified with the P-RNTI = 0xFFFE.

Multiplexing of data units from logical channels to transport channels is one of the
tasks of the MAC layer.

109
Logical channels are differentiated with LCIDs. A CCCH always has LCID = 0. other UE
dedicated channels start with LCID = 1.

A MAC PDU consists of a MAC payload part and a MAC header part. The MAC payload
conveys multiple units of MAC control elements and MAC SDUs from higher layers.

Therefore the MAC sub-headers describe the MAC payload units. There are various
possible combinations of MAC control elements, MAC SDUs and MAC padding
derivatives.

An example of a MAC PDU with a combination of MAC sub-headers, MAC control

elements and MAC SDUs in the payload is depicted above.

Logical channels which are multiplexed to transport channels are prioritised by the
scheduling algorithm. This algorithm decides what to schedule on which physical
resources.

There is only one MAC entity per UE; thus, the UL within the UE has one MAC entity
and the eNB executes multiple parallel entities in the DL direction in case the eNB has
to handle multiple UE.

110
The MAC layer implements a soft combining N-process stop-and-wait FEC detection
mechanism or HARQ (Hybrid automatic Repeat Request).

Transort blocks are protected with a FEC algorithm known as turbo codes. Soft
combining means not correctly decoded blocks are not acknowledged in order to
conduct a retransmission, but the previous received not decoded block is held in a
soft buffer to be combined with the retransmission.

This process of soft combining two or more receptions increases the chance that the
last received retransmission can be decoded error-free.

111
The RLC layer uses SAPs of the MAC layer which are logical channels. Those SAPs are
used to induct its RLC PDUs from the RLC entities.

The RLC layer instead provides basically three types of SAPs to the PDCP layer above
the RLC layer.

The SAPS provide access to the three operating modes to convey data PDUs, either to
the control plane or user plane.

Transparent Mode (TM), Unacknowledged Mode (UM) and Acknowledged Mode

(AM). Basic operating entities of the RLC layer are depicted above.

112
The TM transmits PDUs from the upper layer transparently, which means that the RLC
layer is basically just storing and forwarding those PDUs.

No feedback is requested on whether the data units were delivered or not. Packets
are transparently forwarded by keeping them at the same size.

The diagram above illustrates a transmitting and a receiving RLC TM entity.

The TM is used to transmit cell wide channels as UE paging and the broadcast of
system information. It is a typical mode for point-to-multipoint connections without
any feedback from receivers.

Additionally, CCCHs (LCID = 0) are sent by using the RLC TM.

113
In contrast to the TM, the UM adds segmentation and concatenation of PDUs. This
processing step fits higher layer PDUs to the current available transport block size
indicated by lower layers.

Segmentation reduces the size of PDUs by splitting them apart. The diagram at the
top above.

Concatenation instead is merging PDCP SDUs to a larger RLC PDU. The diagram above
at the bottom illustrates this. Again in order to decrease the padding (adding zeros at
the end of a PDU) and use large transport blocks more efficiently.

114
As the name already indicates the UM does not request feedback from the peer RLC
entity within the receiver, like ACKs of received packets.

The UM is used for point-to-point connections and uses error protection of the MAC
layer which uses HARQ.

But on the RLC level no retransmission process is enabled in UM transmissions.

Some higher layer radio bearers allow rare packet loss, for example, IP/UDP traffic or
IP/TCP traffic which is taking care of lower layer packet loss with its own
retransmissions on the application level.

115
Although the MAC layer uses the enabled HARQ procedure with UM, it is still possible
that packets will get lost between RLC peer entities.

This could, for example, occur when the maximum number of retransmissions of the
HARQ process is reached.

Thus, the AM introduces a secondary outer loop ARQ with ACK feedback from the
receiving RLC entity in order to conduct retransmissions of lost packets.

Two stacked ARQ loops, fast retransmissions of HARQ and the outer loop ARQ of the
RLC AM lead to a good protection for point-to-point DTCHs or DCCHs (used, for
example, for RRC and NAS packets).

Furthermore, segmentation and concatenation are applied with the AM as with the
UM in order to fit PDU sizes.

116
Located above RLC is the PDCP layer. The PDCP layer provides direct data transport for
control plane message (RRC & NAS) and for user plane packets.

User plane packets are application layer IP packets as LTE defines only packet-based
(IP) data communications. Thus voice or video is always IP based (VoIP).

SAPs above the PDCP layer are radio bearers which are mapped to TM, UM or AM
SAPs of the RLC layer below.

Sequencing numbering ensures in-sequence delivery of SDUs for the user plane and
control plane of disordered delivered packets of lower layers.

Different sequence number lengths are defined: 5, 7 and 12 bits. The 5-bit sequence
numbers are reserved for Signalling Radio Bearers (SRBs) carrying control plane SDUs.

The 7-bit and 12-bit sequence numbers are dedicated to Dedicated Radio Bearers
(DRBs) conveying user plane SDUs with application layer IP data.

Header compression is a feature for user plane transmission in order to decrease

application header overhead and to increase overall efficiency.

Application headers as IP headers are used for network routing and can be
compressed on such air interface point-to-point transmission links

117
The header overhead is especially large when small packets are used, for example,
with VoIP, where besides the IP and UDP header, also RTP header is in front of the
payload.

Only Robust Header Compression (RoHC) algorithm is applied with LTE. RoHC is
defined by the IETF. Several RFCs can be used with LTE.

Integrity protection for the control plane, for SRBs, is a function of PDCP as well as
ciphering and deciphering functionality.

The format of a PDCP data PDU for the transport of SRB control plane information is
shown above left. Besides the data field with higher layer protocol information, there
is a PDCP sequence number, some reserved spare bits and four octets for integrity
protection message authentication code (MAC-1).

For the user plane, there are two different formats of PDCP PDUs defined: one with a
long 12-bit PDCP sequence number and one with a short 7-bit sequence number
shown above right.

The long sequence number format is used for transporting RLC AM and UM
information , the short sequence number format for transporting RLC TM frames.
The sequence number length for transporting SRB frames is 5 bits.

118
To find the RBs that carry SIBs on the DL-SCH, a SI-RNTI is signalled on the PDCCH. The
SI-RNTI indicates in which RBs the SIB type 1 can be found.

The MIB and SIB 1 are sent periodically (MIB periodicity: 40 ms, SIB 1 periodicity: 80
ms); all other system information messages are flexibly scheduled.

119
120
121
122
123
124
125
126
127