Académique Documents
Professionnel Documents
Culture Documents
Bearers
In a mobile network using the Long Term Evolution (LTE) architecture, bearers are the
tunnels used to connect the user equipment to Packet Data Networks (PDNs) such as
the Internet. In practice, bearers are concatenated tunnels that connect the user
equipment to the PDN through the Packet Data Network Gateway (P-GW).
In older architectures, bearers were known as packet data protocol (PDP) contexts.
One PDP context connects to one PDN location by default (this was the default PDP
context). Other PDP contexts (up to 11) could be established to or from the same
user device. The maximum of 11 still holds in 4G/LTE networks. Figure 1 shows the
relationship between bearers and P-GWs.
In an LTE mobile network, one default bearer is established to a default P-GW whenever
the user equipment device is activated (this means the user equipment is on and has
performed authentication). There must be at least one default bearer to one default
P-GW, but up to 11 other bearers to the same or other P-GWs can be active to a
single user equipment device.
Bearers encapsulate user data with the GPRS tunneling protocol, user plane (GTP-U).
The GTP-U information is in turn sent with UDP and inside IP packets.
Every user equipment device has an always on default bearer for each P-GW to
which it connects. For example, if user equipment connects to the Internet through
one P-GW and a corporate intranet through another P-GW, two default bearers will be
active. In addition, the user equipment can establish other dedicated bearers to other
PDNs, based on quality-of-service (QoS) requirements. For instance, viewing a
streaming video over the Internet could be done over a dedicated bearer. Dedicated
bearers can use a bandwidth guarantee (a guaranteed bit rate, or GBR) or the user
equipment can establish a non-GBR bearer.
The bearer itself is a concatenated tunnel consisting of three portions (in a nonroaming situation), established in the following order:
The S5 bearerThis tunnel connects the Serving Gateway (S-GW) to the P-GW. (The
tunnel can extend from P-GW to PDN service network, but this is not considered here.)
The S1 bearerThis tunnel connects the evolved NodeB (eNodeB or eNB) radio cell
with the S-GW. Handover establishes a new S1 bearer for end-to-end connectivity.
The radio bearerThis tunnel connects the user equipment to the eNodeB (eNB). This
bearer follows the mobile user under the direction of the Mobile Management Entity (MME)
as the radio network performs handovers when the user moves from one cell to another
A concept of secondary PDP context has been introduced in order to have several PDP
contexts sharing the same PDP address and the same access to the external packetswitching network. This concept was introduced for multimedia applications where each
medium type requires specific transport characteristics and is mapped into a specific PDP
context. It is based on the traffic flow template, which is a filtering mechanism used by the
GGSN to route downlink IP packets toward the appropriate medium within the MS.
A given PDP context is in the active state when this PDP address is activated for data
transfer. Before transferring data between an MS and a GGSN, it is necessary that a PDP
context be activated.
PDP context procedures have been defined in order to create, modify, and delete PDP
contexts within the MS, SGSN, and GGSN entities. The SM protocol is used between the MS
and the SGSN and the GTP protocol is used in the controlling plane between the SGSN and
the GGSN for PDP context procedures.
Radio priority. This specifies the priority level used by the MS at the lower layers for
transmission of data related to a PDP context.
Protocol configuration options. This defines external network protocol options
associated with a PDP context. It may contain information about protocols such as the
link control protocol (LCP), the PPP authentication protocol (PAP), the challenge
handshake authentication protocol (CHAP), and the Internet Protocol Control Protocol
(IPCP).
Several PDP contexts can be activated at the same time in the MS. This means that the MS is
able to transfer or receive data at the same time for several applications. Each PDP context
is identified at the MS level, at the SGSN level, and at the GGSN level by the NSAPI. This
identifier will be used to identify the logical link within the MS between the SNDCP entity and
the application layer. An NSAPI is associated with an individual PDP address. When the SGSN
receives a packet from the GGSN addressed to an MS identified by its PDP address, the SGSN
inserts the associated NSAPI in the SNDCP header. Thus when the MS receives a packet from
the SGSN, it identifies the appropriate application layer from the NSAPI parameter included
in the SNDCP header.
Some applications should require at the same time several activated PDP contexts with
different QoS profiles while reusing the same PDP address and other PDP context information
from an existing active PDP context. For example, multimedia applications involve several
flows (e.g., voice and video that request different QoS but the same PDP address and the
same APN). As a result of several PDP contexts activated at the same time with the same
PDP address and the same APN, the different multimedia application flows can be routed
between the MS and the GGSN via different GTP tunnels and possibly different LLC links.
This means that the analysis of PDP address destination cannot be used by GGSN to
determine the NSAPI of the terminated application. In order to route downlink IP packets
toward the terminated application within the MS, the GGSN uses a filtering mechanism called
traffic flow template (TFT) that is defined by a set of packet filters. If several PDP contexts
are associated with a PDP address, a TFT is created by the MS to specify an IP header filter
for each or all but one context. This mechanism allows for the association of one packet filter
with one NSAPI that is the identifier of the PDP context.
Each packet filter consists of a packet filter identifier within a TFT, a packet filter evaluation
precedence that specifies the precedence for the packet filter among all packet filters in a
TFT, and a list of packet filter attributes. Each packet filter attribute is deduced from IPv4 or
IPv6 headers. The MS will define values related to each packet filter attribute. These may or
may not be combined later in a packet filter. Each packet filter contains at least one of the
following packet filter attributes:
Source address and subnet mask-IPv4 or IPv6 address along with a subnet mask;
Protocol number/next header-IPv4 protocol number or IPv6 next header value;
Port numbers-port number or range of port number;
Security parameter index-IPSec security parameter index;
Type of service (TOS)/traffic class and mask-IPv4 TOS octet or IPv6 traffic class octet
along with a mask;
Flow label-an IPv6 flow label.
A TFT is created for a new PDP context using the same PDP address and the same APN as an
existing PDP context but with a different QoS profile. This new PDP context is called a
secondary PDP context and is activated during a secondary PDP context activation
procedure. After a TFT has been created for a new secondary PDP context, it is sent by the
MS to the network during the secondary PDP context activation procedure. A TFT may be
modified during a PDP context modification procedure initiated by the MS. A TFT is deleted
when the associated PDP context is deactivated.
During packet transmission between the MS and the external packet network, the GGSN will
compare the parameters of the IP PDU header with packet filters of the TFT. If a match is
found between the IP PDU header and a packet filter, the GGSN is able to direct the IP PDU
from the interconnected external PDN to the suitable activated PDP context identified by the
NSAPI parameter. This is illustrated in Figure 7.17.
state set to ACTIVE means that a PDP context is activated in the MS, the SGSN, and the GGSN with a PDP
address in use and routing information for packet transfer between the MS and the GGSN. Data transfer is
possible in this state. The MS will be attached for GPRS services to be in ACTIVE PDP state.
Figure 7.18 shows the transition between the PDP states.
7.2.5 SM Layer
The SM layer handles the PDP context procedures such as PDP context activation, deactivation and
modification, and secondary PDP context activation, between the MS and the SGSN.
The PDP context procedures handled by the SM layer can be performed for a given MS only if a GMM context
has been established. Otherwise, the GMM layer must establish a GMM context for the use of the GPRS-attach
procedure.
All PDP context procedures processed by SM peer entities require a TBF connection on the radio interface.
Initiated by GGSN
When the network receives an IP packet from an external network, the GGSN checks if a PDP context is
already established with that PDP address. If not, the GGSN sends a PDU NOTIFICATION REQUEST to the
SGSN in order to initiate a PDP context activation. The GGSN has retrieved the IP address of the appropriate
SGSN address by interrogating the HLR from the IMSI identifier of the MS. The SGSN then sends to the MS a
request to activate the indicated PDP context. Next the PDP context activation procedure follows the one
initiated by the MS. Once the PDP context is activated, the IP packet can be sent from the GGSN to the MS.
Figure 7.20 illustrates a PDP context activation procedure initiated by the GGSN.
The PDP context modification procedure is used to change the negotiated QoS, the radio priority level, or the
TFT parameters negotiated during the PDP context activation procedure. This procedure may also be used to
change the MS PDP address by the GGSN. The PDP context modification may be initiated by the MS, the
SGSN, or the GGSN. The PDP context modification procedure initiated by the MS or GGSN was introduced in
Release 99 of the GPRS recommendations, even though the PDP context modification procedure initiated by
the SGSN was already introduced in Release 97 of the GPRS recommendations.
Initiated by SGSN
The PDP context modification initiated by the SGSN may occur after an inter-SGSN RA update procedure to
change the negotiated QoS, the radio priority level, or the TFT negotiated during the PDP context activation
procedure.
The SGSN sends an UPDATE PDP CONTEXT REQUEST message to the GGSN with a new QoS. The GGSN
then checks if the new QoS is compliant with its capabilities and sends back to the SGSN in an UPDATE PDP
CONTEXT RESPONSE message the negotiated QoS that takes into account if necessary some restrictions.
The SGSN then sends new QoS parameters and a new radio priority parameter to the MS in a MODIFY PDP
CONTEXT REQUEST message. If the MS accepts the new QoS parameters, it acknowledges the MODIFY
PDP CONTEXT REQUEST message by sending to the SGSN a MODIFY PDP CONTEXT ACCEPT message.
Figure 7.24 illustrates a PDP context modification procedure initiated by the SGSN.
Initiated by GGSN
The GGSN initiates the procedure by sending to the SGSN an UPDATE PDP CONTEXT REQUEST message,
which includes the desired QoS. A PDP address may be provided to the SGSN by the GGSN. Next, the SGSN
sends to the MS the radio priority and packet flow ID on the requested QoS, which may be restricted if
necessary in the MODIFY PDP CONTEXT REQUEST message. The MS acknowledges the requested QoS by
sending to the SGSN a MODIFY PDP CONTEXT ACCEPT message; the SGSN then sends this
acknowledgment to the GGSN in the UPDATE PDP CONTEXT RESPONSE message.
Figure 7.26 illustrates a PDP context modification procedure initiated by the GGSN.