1.6.4.1 Home Routed Roaming Architecture

The roaming architecture, that is, the UE is served by a VPLMN, is not much different from the non-roaming architecture. Main difference between non-roaming and roaming architecture is that in the roaming case S-GW is located in the VPLMN while P-GW is usually located in the HPLMN as most of the traffic is home routed traffic. Only if local breakout is used, the P-GW can be located in the VPLMN, but this scenario requires special arrangements between operators (e.g., usage of special Access Point Names (APN), providing charging information from VPLMN to HPLMN) and the user must be subscribed to this service. Thus, home routed traffic is the dominant usage scenario for PS services until now and this may be true also in the near future. The roaming architecture in the home routed scenario is shown in Figure 1.3.

As can be seen the S5 interface is replaced by S8 in roaming cases and in fact both are providing nearly identical functionality. This is similar to usage of Gn/Gp interfaces (see TS 29.060 [8]) in 2G/3G. S8 is either based on GTP or PMIP like S5. However, using PMIP for S8 requires either appropriate roaming agreements between operators or the VPLMN needs an interworking function to translate PMIP into GTP at the network border.

1.6.4.2 Local Breakout Roaming Architecture

Finally, we show the roaming architecture for local breakout to use services accessible via the VPLMN. The key point in this scenario is that the P-GW is located in the VPLMN and a Visited PCRF (V-PCRF) exists in the VPLMN as well to terminate the Gx interface (Gx is not an inter-operator interface). To receive QoS rules from HPLMN where the subscription data are stored (e.g., the subscribed maximum bit rate), a new interface S9 was introduced that connects the Home PCRF (H-PCRF) in HPLMN with the V-PCRF in VPLMN.

One possible solution to obtain VPLMN services requires the use of specially constructed APNs that are configured in the UE and used in the VPLMN to resolve them to a P-GW address in the VPLMN. Another possible solution is for UEs to use well-known standardized APNs like the IMS APN (see also Section 1.7) defined by Global System for Mobile Communications Association (GSMA) to get connectivity to a P-GW in the VPLMN.

As can be seen from Figure 1.4, the user can potentially use operator services in the HPLMN and VPLMN when local breakout is deployed.

1.6.5.1 User Equipment, Mobile Equipment, and the Universal SIM

In 3GPP terminology the UE is a device used by the end user for communication with the network. It is typically a smartphone, tablet, or modem equipped with LTE radio and is most often multiradio capable, that is, equipped also with other radios such as WLAN, cdma2000® 1xRTT, UTRAN, and GERAN. A UE consists of a Mobile Equipment (ME) part, which is the phone hardware that might be constituted of display, keypad, battery, and all electronics necessary to access and communicate with the network and providing the interface to the user. The only other piece of hardware required to form a UE is a Universal Integrated Circuit Card (UICC), which according to the definition in 3GPP TS 21.905 [9] is a “physically secure device, an IC card (or “smart card”), that can be inserted and removed from the terminal. It may contain one or more applications. One of the applications may be a USIM.”

The Universal Subscriber Identity Module (USIM) contains all data and algorithms necessary to authenticate the UE and verifying the authenticity of the network (only in case of UMTS and LTE). Frequently, the terms UICC and USIM are referred to as Subscriber Identity Module (SIM), as this is the term used in the predecessor organization of 3GPP, the ETSI Special Mobile Group (ETSI SMG).

In addition to the USIM application, the UICC can also contain other applications like the IMS – SIM (ISIM) that provides all necessary data for the UE to access the IP Multimedia Services domain.

A typical UE must go through a series of steps to request and manage a service. When it powers on it needs to perform the following steps:

1. Scanning for a LTE cell, synchronize with the network, and listen for system information over the broadcast channels.
2. Establish a signaling connection in order to communicate with the network.
3. Register with the network.
4. Establish a data connection to be “always-on.”
5. Respond to authentication requests when initiated by the network.
6. Receive an IP address for IP connectivity.

Afterwards the UE can request for specific resources that are needed to run one or more applications.

1.6.5.2 E-UTRAN Node B (eNodeB/eNB)

Main part of the E-UTRAN architecture is the eNodeB. The name is derived from the NodeB in UMTS and just extended with the letter “e” that stands for “evolved.” It is the base station that is in control of all radio-related functions. It is typically deployed throughout the network coverage area, each eNodeB resides near the actual radio antennas. As the eNodeB is the only E-UTRAN node it consists of functions that reside in UMTS in the NodeB and partly in the RNC (other RNC functions were moved to the MME).

It terminates the radio protocols from the UE and relays data between UE and EPC. It supports the following main functions:

• Ciphering/deciphering of user plane traffic, IP header compression, and decompression.
• Radio Resource Management (RRM) functions including radio bearer control and admission control.
• Scheduling traffic according to the assigned Quality of Service (QoS), constant monitoring of the resource usage situation, and radio resource allocation in both uplink and downlink directions toward the UE.
• Mobility management functions: controls and analyzes the radio signal level measurements carried out by the UE, performs measurements, and takes handover decisions for UE(s) based on current radio link quality.
• Select a MME and route the data traffic to the S-GW.

The eNodeBs are interconnected by the X2 interface, connected to the MME by the S1-MME (control plane) interface, and connected to the S-GW by the S1-U (user plane) interface. Note that an eNodeB can connect to multiple MME(s) and/or multiple S-GWs for load balancing and network sharing purposes.

1.6.5.3 Mobility Management Entity (MME)

The MME is the main control element in the EPC. It is derived from the control plane part of the 2G/3G SGSN, enhanced with some functions that were inherited from the 3G RNC. Typically a MME will be a server in a secure location in operator's premises. The MME is only part of the control plane path. User plane data bypass the MME. Thus, the MME has no charging functions, except when it supports the feature “SMS in MME” (see Section 1.8.2).

Besides physical connections to the eNodeB, the MME has also a logical connection with the UE. This logical connection is referred to as Non Access Stratum (NAS). A description of NAS and Access Stratum (AS) can be found in Section 1.13.3. The MME connects also to the user's home HSS to authenticate and authorize the UE and retrieve subscription data. In a nutshell, MME supports the following functions:

• Control plane traffic handling (termination of signaling from the UE).
• Session and mobility management, for example, idle mode mobility and handover control.
• Paging of UE(s) that are in idle mode.
• TA list management.
• Selection of P-GW and S-GW.
• MME selection during handover.
• Coordinates inter-S-GW and inter-MME relocations.
• Authentication and authorization of the UE.
• Bearer management including dedicated bearer establishment.
• Lawful interception of signaling traffic.

1.6.5.4 Serving Gateway (S-GW)

Main function of the Serving Gateway is routing user plane packets between E-UTRAN and P-GW. The S-GW is derived from the user plane part of the 2G/3G SGSN. It is part of the network infrastructure and can be deployed centrally or decentrally in the network. It acts as the local anchor point for inter-eNodeB mobility. If a bearer was established for a certain UE and the UE is in idle mode, that is, there is no signaling connection between UE and network, the S-GW will buffer incoming data packets and request the MME to page the UE. The S-GW is connected to one or more P-GW(s). For each UE and each bearer, a tunnel between S-GW and P-GW is established. The S-GW supports the following functions:

• User plane anchor for mobility between 2G/3G and LTE and for inter-eNodeB handover.
• Lawful Interception (LI).
• Packet buffering and initiation of paging.
• Packet routing and forwarding.
• Transport level packet marking.
• Generation of charging events for interoperator accounting in case of roaming.

1.6.5.5 Packet Data Network Gateway (P-GW)

The P-GW is the first IP hop router from UE point of view and the edge router between the EPS and external PDNs. It is the central mobility anchor and acts as the IP point of attachment for the UE. The UE may be connected to multiple PDNs at the same time through the same or different P-GWs (connecting to different P-GWs is in practice rather unusual). During handover the P-GW is not changed. It is anchoring the user plane for inter-S-GW mobility by maintaining tunnels per UE and bearer toward the S-GW. It is also part of the network infrastructure maintained centrally in operator premises.

One important function of the P-GW is the allocation of an IP address to the UE per PDN connection. On the basis of the particular PDN this can be a private or public IPv4 address or an IPv6 prefix.

On the basis of dynamic or static policy rules the P-GW performs enforcement functions such as shaping, gating, filtering, and packet marking. More precisely, enforcement is done in the Policy Enforcement Function (PCEF), which is an integral part of the P-GW. It ensures that the downlink data rate does not exceed the allowed (i.e., subscribed) maximum bit rate for a particular user and that data packets received in downlink direction are using the correct bearer/tunnel (this is called bearer binding). Following are the main functions supported by the P-GW:

• Edge router to other networks.
• Allocation of IP addresses to the UE.
• Central mobility anchor.
• Policy and Charging Enforcement, bearer binding.
• Packet Filtering (optionally Deep Packet Inspection).
• Accounting per UE and per bearer.
• Lawful Interception.

1.6.5.6 Policy and Charging Rules Function (PCRF)

The Policy and Charging Rules Function (PCRF) is responsible for dynamic policy and charging control (PCC). For more details on PCC, see Section 1.6.7. It is usually located in the operator premises along with other core network elements, for example, close to the P-GW.

The PCRF translates session data coming from the application layer (e.g., information on the codec used for a multimedia session) into access specific parameters. On the basis of these parameters it generates so-called PCC rules that specify which kind of QoS is applicable for which IP flows. These rules are installed and later on executed in the Policy Control Enforcement Function (PCEF) that is part of the P-GW. These rules also specify whether the P-GW should grant resource requests and whether it is allowed to process packets for a given IP flow. The PCRF takes subscription information (e.g., the maximum allowed bit rate) stored in the Subscriber Profile Repository (SPR) into account to make its decisions. The SPR is usually part of the HSS. In the 3GPP architecture the SPR has Sp interface to the PCRF, but this interface was never specified. If GTP is used between S-GW and P-GW, QoS rules are provided from PCRF to P-GW as P-GW can send QoS parameters further down to the RAN via GTP. If an operator decides to use PMIP between S-GW and P-GW, bearers are terminated in the S-GW as PMIP has no bearer concept implemented. In this case, QoS rules are provided from the PCRF to the S-GW while policy and charging rules are still provided to the P-GW.

1.6.5.7 Home Subscriber Server (HSS) and Subscriber Profile Repository (SPR)

The HSS is the central database for all subscriber related data in the network. It contains subscriber-specific data such as International Mobile Subscriber Identity (IMSI), Mobile Station International ISDN Number (MSISDN), subscribed APN, priority indication, and subscribed supplementary voice services (e.g., call forwarding). It is centrally located in the operator premises. The HSS contains logically the Home Location Register (HLR) function that is the central register in legacy 2G/3G networks. Originally the HSS function was introduced with 3GPP Release 5 to host IMS subscription data like the IMPI and IMPU(s).

Although the SPR is an extra functional entity defined by 3GPP, it is usually (in real-life implementations) collocated with the HSS. The SPR contains subscription information that is used by the PCRF to make policy decisions and generate appropriate PCC rules. Such data are, for example, the maximum allowed bit rates for a user, the subscribed guaranteed bandwidth, whether user has a prepaid or postpaid contract and whether user receives preferred treatment based on his status (“bronze,” “silver,” and “gold” users).

The HSS is involved in user authentication and authorization and other security-related functions, generating and storing keys, parameters for ciphering, mutual authentication, and message integrity checking. The HSS also records user's physical location (the addresses of MME, SGSN, and MSC serving the user). More than one HSS may be present in the network, depending on the number of subscribers and capacity of the hardware platform. In this case, identifiers such as MSISDN or IMSI can be used to select the correct HSS.

When the MME authenticates the user and authorizes the user request to access network resources (e.g., authorizing the APN provided by the UE), it needs access to the subscription data stored in the HSS. The HSS provides also the security key K_ASME from which the MME derives the security keys to cipher and integrity protect NAS messages exchanged between UE and MME. For location management purposes, the HSS stores the addresses of MME serving a particular UE.

1.6.5.8 Authentication, Authorization, and Accounting (AAA) Function

The Authentication, Authorization, and Accounting (AAA) server (not shown in the various architecture figures) is either used to authenticate and authorize users who are accessing the EPC through non-3GPP access systems or, optionally, by the P-GW to authorize usage of the provided APN and to allocate an IP address to the UE. The P-GW uses RADIUS or DIAMETER according to 3GPP TS 29.061 [10] to access the AAA server via the SGi interface. The operator's AAA server can also work as an AAA proxy and interwork with AAA servers of other PLMN(s) or in company networks. It is centrally located in the operator premises and has a direct interface to the HSS.

1.6.6.1 Quality of Service and EPS Bearers

The EPS provides IP connectivity between a UE and a packet data network external to the PLMN. This is referred to as PDN connectivity service. An EPS bearer uniquely identifies traffic flows that receive a common QoS treatment. It is the level of granularity for bearer level QoS control in the EPC/E-UTRAN. All traffic mapped to the same EPS bearer receives the same bearer level packet forwarding treatment. Providing different bearer level packet forwarding treatment requires separate EPS bearers.

An EPS bearer is referred to as a GBR bearer, if dedicated network resources related to a Guaranteed Bit Rate (GBR) are permanently allocated once the bearer is established or modified. Otherwise, an EPS bearer is referred to as a non-GBR bearer.

Each EPS bearer is associated with a QoS profile including the following data:

• QoS Class Identifier (QCI): A scalar pointing in the P-GW and eNodeB to node-specific parameters that control the bearer level packet forwarding treatment in this node.
• Allocation and Retention Priority (ARP): Contains information about the priority level, the pre-emption capability, and the pre-emption vulnerability. The primary purpose of the ARP is to decide whether a bearer establishment or modification request can be accepted or needs to be rejected due to resource limitations.
• GBR: The bit rate that can be expected to be provided by a GBR bearer.
• Maximum Bit Rate (MBR): Limits the bit rate that can be expected to be provided by a GBR bearer.

Following QoS parameters are applied to an aggregated set of EPS bearers and are part of user's subscription data:

• APN Aggregate Maximum Bit Rate (APN-AMBR): Limits the aggregate bit rate that can be expected to be provided across all non-GBR bearers and across all PDN connections associated with the APN.
• UE Aggregate Maximum Bit Rate (UE-AMBR): Limits the aggregate bit rate that can be expected to be provided across all non-GBR bearers of a UE.

The UE routes uplink packets to the different EPS bearers based on uplink packet filters assigned to the bearers while the P-GW routes downlink packets to the different EPS bearers based on downlink packet filters assigned to the bearers in the PDN connection.

Figure 1.5 shows the nodes where QoS parameters are enforced in the EPS system.

1.6.6.2 Session and Bearer Management

With Session and Bearer Management procedures, EPS bearers for a particular UE are established and maintained. The default EPS bearer context is activated during the EPS Attach procedure. Upon successful attach, the UE can request setting up connections to additional PDNs. For each additional PDN connection, the MME activates a separate default EPS bearer. A default EPS bearer context remains activated throughout the lifetime of the PDN connection. Each PDN connection is characterized by the IP address that is assigned to this connection.

A dedicated EPS bearer is always linked to a default EPS bearer and inherits from it characteristics like the IP address, that is, UL traffic on a dedicated bearer uses the same source IP address as traffic on the default bearer. A dedicated bearer is used when additional EPS bearer resources with a specific QoS between UE and PDN are required. The distinction between default and dedicated bearers is transparent to the eNodeB. As an example: In case of VoLTE (see Section 1.8.1) voice and video streams use dedicated bearers associated with the IMS PDN connection while IMS/SIP signaling can use the default EPS bearer. A dedicated bearer is established via the dedicated bearer context activation procedure. It can either be part of the attach procedure or initiated together with the default EPS bearer context activation procedure. The procedure is usually initiated by the network, but may be also requested by the UE. If the UE requests additional EPS bearer resources, the network decides whether to fulfill such a request by activating a new dedicated bearer or modifying an existing dedicated or default bearer.

By using the PCC framework the network can initiate the activation of dedicated EPS bearers together with the activation of the default EPS bearer or at any time later, as long as the default EPS bearer remains activated.

Default and dedicated EPS bearers can be modified. Dedicated EPS bearers can be released without affecting the default EPS bearer. If the default EPS bearer is released, all dedicated bearers linked to it are also released.

Readers interested in detailed call flows for UE-requested PDN connectivity request and network-initiated dedicated bearer activation procedure may refer to the Appendix.

1.6.6.3 IP Address Allocation

The network can assign three types of IP addresses to the UE once it connects to the network: either a private or public IPv4 address or an IPv6 prefix or both. The IP address can be allocated by the HPLMN, VPLMN (in case of local breakout), or potentially by an external service provider (e.g., a company network).

The type of IP address allocated to the UE depends on the PDN connection and on UE capabilities. The HSS stores one or more PDN types per APN in the subscription data. During Attach or UE-requested PDN connectivity procedure, the MME takes the requested and the subscribed PDN types into account before finally determining the PDN type for the connection.

DHCPv4 or 3GPP-specific signaling during PDN connection establishment is used to deliver an IPv4 address to the UE. IPv6 stateless address auto-configuration is used to assign a 64-bit globally unique prefix to the UE. If a shorter prefix has to be allocated for a PDN connection, it is delivered using DHCPv6 prefix delegation after the UE has first received the 64-bit prefix with stateless auto-configuration. It has to be noted that neither DHCPv4 nor DHCPv6 prefix delegation is currently widely used in live networks. In most of the cases, an AAA server assigns an IP address for a PDN connection and provides it to the P-GW via SGi signaling (RADIUS or DIAMETER).

1.6.8.1 Control Plane

The control plane consists of all protocols used for signaling between UE and network or between two network entities.

UE – eNodeB – MME

Figure 1.7 shows the control plane protocol stack between UE, eNodeB, and MME.

A description for the 3GPP defined protocols (white background in the figure) and corresponding reference specifications are provided here. Other protocols based on IETF standards are not described.

Non Access Stratum (NAS)

NAS is the highest layer of the control plane between UE and MME at the radio interface. Main functions of the NAS protocol are the support of mobility of the UE and the support of session management procedures to establish and maintain IP connectivity between UE and P-GW. For further details, refer to 3GPP TS 24.008 [13], 3GPP TS 24.301 [14], and 3GPP TS 23.122 [15]. See also Section 1.13.3 for a comparison of NAS and AS.

Radio Resource Control (RRC)

RRC is the primary control protocol of the LTE–Uu interface, which is the interface between UE and eNB. It is responsible for a wide variety of system functions, including system information over the broadcast channel, radio configuration (set up, maintenance, and teardown of radio resources), measurements, and mobility. For further details, please refer to 3GPP TS 36.300 [16].

Packet Data Convergence Protocol (PDCP)

PDCP is responsible for ensuring the integrity of packets sent over the air interface. In addition, the PDCP layer compresses the IP header of a data packet. For further details, please refer to 3GPP TS 36.300 [16].

Radio Link Control (RLC)

RLC provides a logical link control mechanism over the air interface. Main task of RLC is the segmentation of PDCP packets in smaller parts that can be transmitted over the air. For further details, please refer to 3GPP TS 36.300 [16].

Medium Access Control (MAC)

The MAC layer selects a transport channel to transmit data and manages the mapping of logical channels to transport channels. In addition, the MAC layer is responsible to multiplex data to common and shared channels. For further details, please refer to 3GPP TS 36.300 [16].

Physical Layer (PHY)

This is the layer 1 of the LTE–Uu interface. Physical channels differentiate the source of the transmission as well as its destination. A particular message may be destined for a specific UE (a handover command) or may be intended for all active UE(s) (system broadcast messages). For further details, please refer to 3GPP TS 36.300 [16].

S1-Application Protocol (S1AP)

S1AP provides the signaling service between E-UTRAN (eNB) and the EPC (MME). S1AP services are divided into two groups:

• Non-UE-associated services: They are related to the whole S1 interface between the eNB and MME utilizing a generic signaling connection.
• UE-associated services: They are related to one UE. S1AP functions that provide these services are associated with a UE-associated signaling connection that is maintained for the UE.

For further details, please refer to 3GPP TS 36.413 [17].

eNodeB–eNodeB

Figure 1.8 shows the control plane protocol stack between two eNB(s) (X2 control reference point).

X2-Application Protocol (X2AP)

X2AP is used for mobility management procedures between two eNB(s) including handover preparation. In general, it is used to maintain the relationship between two eNBs. For further details, please refer to 3GPP TS 36.423 [18].

MME–S-GW–P-GW

Figure 1.9 illustrates the control plane protocol stack between any two network elements that support the GTP-C protocol. This can apply for MME–S-GW (S11 interface), MME–MME (S10 interface), and S-GW–P-GW (S5/S8-GTP-C-based interfaces).

Short description for GTP-C (3GPP defined protocol) is provided here. Other protocols are based on standard IETF techniques.

GPRS Tunneling Protocol for the Control Plane (GTP-C)

Main purpose of GTP-C is to establish and maintain bearer tunnels (GTP-U tunnels) associated with bearer contexts in LTE/SAE for user sessions that require a certain QoS. For that purpose, GTP-C enables the exchange of tunnel identifiers and tunnel addresses (IP addresses, port numbers) between the two involved entities. Such tunnels exist between radio and core network and within the core network. In EPC, the GTP tunnel is established between eNB and S-GW and between S-GW and P-GW. Together with the bearer on the radio interface between UE and eNB, this results in an end-to-end bearer with a certain QoS spanning from the UE toward the P-GW. Besides that GTP-C is also used to transport mobility management messages in case of relocation/handover. For further details refer to 3GPP TS 29.274 [19].

MME – HSS

Figure 1.10 shows the control plane protocol stack between MME and HSS.

S6a DIAMETER Application

Main function of S6a is to support transferring of subscription and authentication data for user authentication and authorization between MME and HSS. DIAMETER is defined in RFC 3588 [20] and the S6a DIAMETER application in 3GPP TS 29.272 [21].

1.6.8.2 User Plane

Figure 1.11 shows the end-to-end user plane stack for a UE connecting toward a P-GW in EPS.

The protocol stack is similar to the control plane stack. The only new protocol being introduced here is GTP-U.

GPRS Tunneling Protocol for the User Plane (GTP-U)

This protocol tunnels user data between eNodeB and eNodeB, eNodeB and S-GW, as well as between S-GW and P-GW. GTP-U encapsulates all user plane packets. For further details on GTP-U, please refer to 3GPP TS 29.281 [22].

1.6.8.3 Summary of Reference Points and Protocols

Table 1.3 summarizes the reference points and protocols used for LTE/SAE and PCC.

1.6.9.1 Attach

Each UE needs to register with the network to receive EPS services. This registration is called “network attachment.” Always-on IP connectivity for a UE is enabled in EPS by establishing a so-called default EPS bearer during network attachment. The UE may request an IP address during the Attach procedure. The Attach procedure is triggered by the UE by sending an Attach Request message to the network. This message terminates at the MME. The Attach Request message is encapsulated in a RRC message toward the eNB and in a S1-MME control message to the MME. The MME that terminates the Attach Request message is called “serving MME.” Its address is stored in the HSS.

One purpose of the Attach procedure is to authenticate the UE and activate integrity protection and ciphering of NAS messages exchanged between UE and MME. Necessary information for the authentication of a particular UE is obtained from the HSS. This information consists of so-called authentication vectors that are generated in the HSS from the keys stored in the subscription data.

If dynamic policy control is applied, the P-GW obtains PCC rules for the UE from the PCRF during the Attach procedure. If dynamic policy control is not deployed, the P-GW may apply local QoS policies. This could result in the establishment of a number of dedicated bearers for the UE in association or combination with the default bearer.

Finally, the UE is registered with the network to receive EPS services. It can request for specific resources to run a certain application and perform handover when radio coverage conditions change.

1.6.9.2 Detach

The Detach procedure allows the UE to inform the network that it does not want to access the network any longer and allows the network to inform the UE that it does not have access to the network any longer. Detaching a UE implies that all PDN connections and associated bearers are released.

The UE is detached either explicitly or implicitly. In case of an explicit detach, the network or UE explicitly requests detach and signal with each other. In case of an implicit detach, the network detaches the UE without notifying the UE. This is typically done when the network presumes that it is not able to communicate with the UE, for example, due to lack of radio coverage.

1.6.9.3 Tracking Area Update

Once the UE is successfully attached, it needs to keep the network informed about its current location in order to be reachable for downlink signaling and user data (incoming voice call or SMS) even when the UE is in “idle mode,” that is, when the signaling connection between UE and network has been released. Moving in idle mode and keeping the network informed about its current location is in general referred to as “idle mode mobility.” Although normally not active in idle mode the UE periodically wakes up and monitors the broadcast channel in order to receive information about incoming signaling or data traffic.

E-UTRAN cells are combined to Tracking Areas. A UE camping on an E-UTRAN cell in idle mode is listening to the system information broadcast in this cell, which includes the identity of the TA the cell belongs to. When the UE moves to another cell and the received TA identity indicates that the new cell belongs to a TA to which the UE is currently not registered (i.e., the TA is not in the list of registered TAs stored in the UE), the UE initiates a TA updating procedure.

In the simplest case, if the new cell and the new TA are served by the same MME to which the UE is already registered, only two NAS messages, TA Update Request and TA Update Accept, need to be exchanged between UE and MME. Otherwise, if the new cell is served by a new MME, or if the MME decides to change the S-GW, further network entities (HSS, old MME or old SGSN, old S-GW, P-GW) need to be involved in the procedure.

The TA or list of TAs allocated by the MME during the TA updating procedure or attach procedure can be used by the MME to page the UE in a certain area, when the signaling connection to the UE has been released and the network needs to send downlink signaling or user data. The MME can page the UE first in the last known TA, if the UE does not respond, paging can be performed in a wider area (e.g., in neighboring TAs) before the MME pages the UE in all TAs of the allocated TA list. The MME knows the location of a UE only up to the granularity of a TA, and it has no knowledge in which particular cell of a TA the UE is currently camping on.

1.6.9.4 Paging

The paging procedure is normally initiated by the network to request the establishment of a NAS signaling connection toward an UE that is in idle mode. In addition, the network can also initiate paging to inform the UE in RRC-IDLE or RRC-CONNECTED mode about system information change, inform the UE about an impending warning notification (e.g., for CMAS and ETWS as described in Chapter 2). It can also be initiated by the network to request the UE to perform re-attach when the network has lost UE context due to a failure situation.

The trigger for paging a UE is usually a mobile-terminated transaction destined for the UE such as downlink data, an incoming SMS, or voice call.

It is up to the network (i.e., the MME) to decide how and with which priority to page the UE. The paging could be, for example, started in the last known cell and then extended to a wider area such as TA and TA list. Priority of paging can be determined by the bearer QCI and ARP.

When the UE is in RRC-IDLE state, the UE periodically monitors for a paging message from the network. The monitoring frequency in the UE is determined by the “Discontinuous Reception (DRX) cycle in idle mode.” This idle mode DRX value can be configured via the Broadcast Control Channel (BCCH) and the NAS layer. If the UE has to monitor paging periodically, this consumes some power (i.e., battery life) in the UE. Thus, in Release-12, 3GPP introduced a new mode called “Power Saving Mode (PSM)” in order to provide additional means to save battery life for devices that normally require only infrequently mobile-originated transactions. When UE is in PSM, idle mode procedure does not apply, that is, UE does not listen to paging nor perform measurements. Thus, the UE is not reachable for mobile-terminated transactions. This is meant mainly for devices (e.g., with frequency such as twice a day transmission, 8 bytes a day transmission) for which mobile-terminated transactions are very infrequent or some delay in mobile-terminated transactions is acceptable without impacting the end user experience.

1.6.9.5 Service Request

The purpose of the Service Request (SR) procedure is to move the UE from ECM-IDLE to ECM-CONNECTED state and establish EPS bearers when user or signaling data have to be transmitted. Other purposes are to trigger MO/MT CS Fallback (CSFB), explained later in this chapter, and Proximity Services procedures (see Chapter 4).

If the UE has a pending mobile-originated transaction when it is camping in E-UTRAN, then the UE initiates a Service Request procedure toward the network. If the network has a pending mobile-terminated transaction, the network initiates a paging procedure first. Once the paging message has been successfully processed by the UE, it responds with a Service Request message toward the network to establish the necessary bearers.

The NAS Service Request message is used for fast re-establishment of the NAS signaling connection and the user plane bearers. In order to meet the strict performance requirements for EPS when it is sent as a response to a paging message, the NAS Service Request message transmitted over the air was carefully designed to fit within a single-radio transport block so that the message need not be segmented over the air interface.

When new features caused the addition of information elements, this requirement could no longer be met. For this reason, a new Extended Service Request (ESR) message was defined. ESR is used in special cases (e.g., to trigger a CS Fallback procedure) when additional parameters need to be sent. ESR follows the layout of regular EMM messages.

Thus, the Service Request procedure can be initiated using a regular Service Request or an Extended Service Request. The detailed conditions for when to use Service Request or Extended Service Request are specified in 3GPP TS 24.301 [14].

Successful completion of a Service Request procedure is determined by the UE either based on indication of successful establishment of radio bearers (when the UE continues to remain in E-UTRAN) or based on successful intersystem change (in case of CS Fallback).

1.6.10.1 General

“Handover” refers to situations where the UE is moving from one cell to another while it maintains a signaling connection with the network. In case of intra E-UTRAN handover, the UE moves from one LTE cell to another one. Inter-RAT handover refers to the case where source and target cell belong to different radio technologies, for example, UE moves from an E-UTRAN to a UTRAN cell.

In case of intra E-UTRAN handover, the UE can be handed over from the currently serving eNB (“source eNB”) to a new one (“target eNB”). This handover procedure considers also existing data connections, that is, data connections are moved from the source to the target eNB. The handover process can even lead to a change of the serving S-GW and/or MME once the UE has moved into a service area that is no longer served by the old S-GW and/or MME. Only the P-GW as mobility anchor point is never changed during handover.

Two different signaling procedures have been defined for handover: X2-based and S1-based handover, named after the interface used for the exchange of signaling messages during the handover preparation.

1.6.10.2 X2-Based Handover

If both eNBs are connected to the same MME, source eNB and target eNB can exchange the S1AP signaling for the handover preparation and execution directly via the X2 interface (for details, see 3GPP TS 36.300 [16]).

The MME is involved in the procedure only during the handover completion phase when the UE has already been handed over to the target eNodeB. During the handover, the target eNB sends an S1AP message (Path Switch Request) to the MME indicating that the S1 interface needs to be switched from the source to the target eNB. Through this message MME is also aware that the UE has moved into a new cell. The MME updates the S-GW with the new address information for downlink user data and confirms the relocation of the S1 interface toward the target eNodeB. If the MME wants to use a different S-GW, it can allocate resources on the new S-GW and provide the target eNB with the necessary address information for sending uplink user data.

During the handover execution, downlink packets are forwarded by the source eNodeB to the target eNodeB. Once the S-GW receives the command to switch the user plane to the target eNodeB, it sends one or several “end marker” packets toward the source eNodeB to assist the target eNodeB with the reordering of packets.

After completion of the handover, the UE receives the system information broadcast in the target cell. If the target cell belongs to a TA to which the UE is not registered, the UE has to initiate a TA update procedure.

1.6.10.3 S1-Based Handover

S1-based handover is used in all cases when X2-based handover cannot be used, for example, when source eNB and target eNB are served by different MMEs (indicated by the TA identity of the target cell). During the handover preparation, the signaling information is exchanged between source eNB and target eNB via the involved MME(s), that is, messages are sent via the S1 interfaces, and possibly via the S10 interface between the MMEs. Independent of a possible MME change also the S-GW can be changed during S1-based handover.

In case of MME change, the source MME transfers context information about the UE to the target MME, including the EPS security context, and mobility management and session management information. For proper routing of uplink data packets, the MME provides the target eNB with the S-GW address.

During the handover execution, downlink packets are forwarded by the source eNB to the target eNB either directly or indirectly, that is, via the target S-GW.

After completion of the handover, the UE receives the system information broadcast in the target cell. If the target cell of the handover belongs to a TA to which the UE is not registered, the UE initiates a TA updating procedure.

1.6.12.1 Charging Principles

EPC nodes provide functions that implement Online Charging and/or Offline Charging mechanisms on bearer level, in particular for the PDP context/IP-CAN bearer, and on Service Data Flow (SDF) level. Online Charging performs traffic supervision in real time, while Offline Charging records the usage of resources (e.g., number of sent/received packages or volume or the duration of voice calls). The collected resource usage data can be used for billing of individual subscribers, inter-operator accounting, or general statistical purposes.

Offline Charging is a process where charging information for network resource usage is collected concurrently. The information is passed from the Charging Trigger Function (CTF) to the billing system. Offline charging does not affect the rendered service in real time.

Online Charging, on the other hand, is a process where charging information for network resource usage is not only collected concurrently during their usage, but also the authorization for using these network resources must be obtained before the actual usage. This authorization is granted by the Online Charging System (OCS) upon request from network functions such as GGSN or P-GW/PCEF. More details of the OCS architecture can be found in 3GPP TS 32.296 [30].

Offline and Online Charging can be performed simultaneously and independently for the same chargeable event, for example, a voice call or packet data transfer.

1.6.12.2 EPC Charging

In case of EPC charging, the following functional entities provide charging data:

• The SGSN, S-GW, and ePDG (see Chapter 1.10) record user's access to VPLMN resources. In addition, the SGSN records user's mobility management activities, SMS, and Multimedia Broadcast/Multicast Service (MBMS) usage.
• The P-GW and GGSN record user's access to external networks such as the Internet.
• The MME record SMS usage when the “SMS in MME” feature is supported.

The functional entities in EPC differ with regards to the charging information they are able to supervise and report. So-called Charging Characteristic profiles stored in the HSS specify under which conditions a certain charging event is generated. Three default profiles exist: one for the non-roaming case, one for the local breakout roaming case, and one for the home routed roaming case. Besides these profiles stored in HSS, SGSN/S-GW and GGSN/P-GW/TDF can also use locally configured profiles.

1.6.12.3 Offline Charging

If a subscriber is using EPS network resources, the corresponding charging information is collected by the EPC functions serving the subscriber. SGSN and S-GW capture information regarding the usage of radio network resources as well as data pertaining to mobility management, while GGSN, ePDG, and P-GW collect charging information that relate to the utilization of external data network resources. The subscriber's usage of resources in the EPC network itself is recorded by each of them. Access to EPC network resources is provided by PDP contexts/IP-CAN bearers that offer the user a logical connection to services with a certain QoS. An APN identifies the service to which access is provided and network resources are consumed. Examples of such services are IMS or Internet access.

The EPC entities collect information pertaining to these PDP context/IP-CAN bearers and the resource utilization that comes along with their usage. EPC charging comprises collecting information about transferred data volume separated for downlink and uplink traffic and categorized by the provided QoS and used protocols, the duration of this usage (i.e., how long the PDP context/IP-CAN bearer is activated), destination, and source address, the APN as well as the location of the UE, that is, the network to which the UE is currently attached to. Regarding the GGSN and P-GW, the accuracy of this location information is limited to the SGSN address, whereas in SGSN and S-GW also the E-UTRAN cell identity is available. The MME plays a role for charging only in case of SMS offline charging when “SMS in MME” feature is supported.

User's activities are recorded in charging events by the Charging Data Function (CDF) and finally formatted into so-called Charging Data Records (CDR) generated in the entities serving the user. The CDR is transferred to a Charging Gateway Function (CGF) for further processing and from there to the Billing Domain (BD).

For EPC charging the creation of a CDR is triggered by a charging event during PDP context/IP-CAN bearer activation (e.g., in P-GW). Thus, EPS bearer context activation is, for example, a chargeable event. At the same time, volume counters for this context are initialized counting the transferred data volume in uplink and downlink. Upon occurrence of certain chargeable events, such as change of QoS or radio access type, these volume counters are captured together with a timestamp and the applied QoS in the collecting node. Other charging triggers, such as deactivation of the PDP context/IP-CAN bearer or operator-defined limits for time or volume lead finally to the closure of the CDR. If the IP-CAN bearer remains active, a new charging record is created. Besides data volume or elapsed time, other data such as user's IP address, protocol type, and APN are also stored in a CDR.

Common information to all CDRs is the IMSI, optionally the MSISDN and the IMEI, identifying the subscriber and the UE.

The CGF receives charging records over the Ga reference point, if it is not integrated in the node sending the records. The CGF can also be a separate entity or part of the BD . The BD is responsible to create the final bill toward the subscriber (e.g., on a monthly basis). In all these cases, charging records are transferred from CDF to CGF via the GTP protocol. The transfer of the CDR files from the CGF to the BD uses the Bp reference point.

1.6.12.4 Online Charging

In contrast to offline charging, the solutions for online charging on the SGSN/S-GW and the GGSN/ePDG/P-GW differ significantly.

The SGSN uses legacy non-IP techniques for online charging while EPC online charging at the GGSN, ePDG, and P-GW uses DIAMETER. Online charging may apply on a PDP context/IP-CAN bearer level or on individual service flow level. EPC online charging at the P-GW and TDF is utilizing the Ro interface and the associated DIAMETER Credit-Control application toward the OCS.

The P-GW (i.e., the PCEF as part of the P-GW) collects charging information on the IP-CAN bearer level for each user separated for uplink and downlink. The defined chargeable events correspond to the ones for offline charging for debiting, that is, start and stop of a PDP context/IP-CAN bearer, reaching of time or volume limits, as well as QoS or tariff time changes. If such events occur, the OCS is informed by the P-GW/PCEF and need to authorize the event beforehand, for example, that a new bearer can be established.

Upon establishment of a PDP context/IP-CAN bearer the P-GW/PCEF requests authorization of this event from the OCS. The OCS either authorizes the request when the answer contains a certain volume and/or time quota or denies the context establishment. If authorization is confirmed, a volume counter and/or time measurement is granted in the P-GW/PCEF that debits the counters based on the traffic transmitted via the PDP context/IP-CAN bearer.

If for an established PDP context/IP-CAN bearer the supplied quota is used, the OCS is requested to perform a re-authorization. In this case the used volume count is reported by the P-GW/PCEF to the OCS. When a change of charging conditions has occurred, this information is used to determine how much of the quota has been consumed for the old QoS and during the tariff time.

Generally, the OCS replies to the P-GW/PCEF with quota and instructions how the P-GW/PCEF shall further proceed, for example, continue or terminate an ongoing session.

1.6.12.5 Flow-Based Bearer Charging

To allow for a service-based charging below bearer level, Flow-Based Charging (FBC) has been introduced with 3GPP Release 6 (see 3GPP TS 23.203 [4]). It adds new functionalities to the EPC network and especially extends the capabilities of the P-GW in such a way, that it is now able to identify different Service Data Flows (SDF) within a single PDP context/IP-CAN bearer.

From the point of view of charging information collection, FBC can be considered as an extension of the classical EPC charging by being able to sub-categorize the total data volume of a PDP context/IP-CAN bearer by the different flows the context/bearer contains. For each of these SDFs, an own uplink and downlink volume counter is required.

With FBC it is possible to employ the same charging models for both offline and online charging and irrespective of whether the subscriber is prepaid or postpaid. FBC provides a high degree of flexibility regarding which SDF to consider and how to recognize a SDF by means of charging rules.

The overall FBC concept is realized by three functional elements: the Policy and Charging Rules Function (PCRF), the Application Function (AF), and the Policy and Charging Enforcement Function (PCEF). The overall PCC architecture is described in Section 1.6.7.

The PCRF provides Charging Rules via the Gx reference point to the PCEF and decides which rules have to be applied based on data received from the PCEF, such as user- and bearer-related information, as well as from the AF, which provides session- and media-related information. Such rules contain information how packets belonging to a flow can be identified and how they shall be treated, in particular regarding the applicable QoS. Charging rules need to be specified for each particular service.

The AF provides services to the user for which PDP context/IP-CAN bearer resources are required. The AF can provide additional information to the PCRF for charging rule selection or generation, such as an application identifier, specific user information, and packet filters allowing for the identification of packets belonging to the respective service data flows.

The PCEF is responsible for identifying the user data traffic based on the charging rules received from the PCRF. It is used for both online and offline charging. In case of online charging, the PCEF has also to take care of Credit Control, that is, maintaining the assigned quota as well as communication with the OCS. The PCEF can be located in the P-GW or in case of untrusted WLAN access in the ePDG.

In case of offline charging, charging information collected by the PCEF is written into a PGW-CDR. When flow-based offline charging is activated in a P-GW, classical IP-CAN bearer charging is not done anymore.

In case of online charging, the PCEF creates charging events to request authorization regarding the resource usage being caused by a SDF. On IP-CAN bearer activation a FBC Credit-Control session is started. The OCS replies with a charging event response either granting an initial quota or denying the service request. Following requests toward the OCS may be triggered when the subscriber starts using a new service, that is, when the PCEF encounters one or more new SDFs or when the granted quota is used up. The charging session is closed when the IP-CAN bearer is deactivated or the OCS indicates session termination as a result of the fact that the subscriber has consumed his or her credit.

1.6.12.6 Charging Rules

FBC uses charging rules to identify and charge SDFs. A SDF consists of one or more IP flows that shall be treated and charged as a whole.

A SDF is identified by means of SDF filters. Such a filter may be an IP 5-tuple containing of destination/source IP addresses, destination/source port numbers and protocol (TCP, UDP, SCTP), possibly with wildcards, and also other filters for application protocol or content recognition and form part of a charging rule. The wildcard represents the so-called default SDF, which comprises all traffic. If it is the only defined SDF in a PCEF, the resulting behavior of FBC corresponds to the classical EPC charging on bearer level. Otherwise, the default SDF captures all traffic that does not match at least one of the more specific flow filters.

Charging rules in the PCEF are applied by matching received packets with the SDF filters that are part of these charging rules. Pre-defined charging rules are completely configured, that is, they contain all necessary information to be applied. They may already be installed on the PCEF or provided by the PCRF via the Gx reference point when needed. In contrast, dynamic charging rules are newly generated or completed dynamically using application-specific criteria to identify the SDF. This information is provided by the AF to the PCRF on request over Rx.

Besides SDF filters, charging rules may comprise further information that, for instance, define how the charging process shall take place, that is, whether time- and/or volume-based resource usage information shall be provided, which precedence the charging rule has in case of a rule overlap, whether online or offline charging has to be applied, and identifiers for charging correlation and service identification.

Charging rule provision takes place over the Gx reference point. The provision of rules can either occur following a charging rule request by the PCEF (caused, e.g., by bearer establishment, bearer modification, or QoS change) or unsolicited by the PCRF as the result of new information received from an AF or via notification received from the OCS.

The Rx reference point plays an important role for dynamic charging rule generation and completion and is used for exchanging information between the PCRF and the AF. When the AF becomes aware of new media used by an application, it provides this information, which in particular relates to the different flows and how they can be identified, to the PCRF, which in turn generates or completes dynamic charging rules by adding SDF filters. This procedure may also be initiated by a PCEF requesting charging rules and a PCRF recognizing that specific information is required for dynamic rule provisioning. The PCRF then contacts the corresponding AF to acquire the needed information.

1.6.12.7 MBMS Charging

For MBMS charging, the BM-SC contains an integrated CTF that generates charging events for mobile subscribers receiving services through the MBMS user service and/or for content providers delivering content through the MBMS bearer service. Transactions involving the content provider are recorded per subscriber. Online charging at the BM-SC utilizes the Ro reference point while offline charging at the BM-SC utilizes the Rf reference point.

The MBMS GW collects charging information for each MBMS bearer service that is activated. Following information is reported by the MBMS GW:

• Start of MBMS bearer context: A CDR for the MBMS bearer context is created and the data volume is captured for the context.
• MBMS bearer context termination in the MBMS GW.
• Expiry of an operator configured time or data volume limit per MBMS bearer context. This event closes the MBMS bearer context CDR and a new CDR is opened, if the context is still active.
• Change of charging condition, for example, tariff time change. In this case the current volume count is captured and a new volume count is started.
• Expiry of an operator configured change of charging condition limit per MBMS bearer context closes the MBMS bearer context CDR. A new CDR is opened, if the MBMS bearer context is still active.

More details on MBMS charging can be found in 3GPP TS 32.273 [31].

1.9.3.1 UE Aspects

In order to interwork with legacy 3GPP access technologies, an UE needs to be multiradio capable. It needs to support idle mode and connected mode mobility between E-UTRAN, UTRAN, and GERAN. There are two modes of interworking defined: single-radio operation and dual-radio operation.

In case of single-radio operation, the network controls the usage of radio transmitter and receiver in the UE in a way such that only one radio is operating at any time. This is optimized interworking and allows UE implementations where only one pair of physical radio transmitter and receiver is implemented. With dual-radio operation, multiple radio transmitters and receivers are operating simultaneously. Single-radio operation is an important mode because different access networks operate in different frequencies that might be close to each other. So, dual-radio operation can cause high interference within the UE. Furthermore, it can consume additional power and reduce the overall performance and is more costly in terms of implementation.

1.9.3.2 E-UTRAN Aspects

The main additional function of the eNB is the support of mobility to and from UTRAN and GERAN. From eNB perspective, it needs to provide similar functionality for mobility to UTRAN and GERAN, for example, neighboring GERAN and UTRAN cells from the same network need to be configured in the eNB. Handover to and from UTRAN/GERAN is performed via the MME.

1.9.3.3 EPC Aspects

The S-GW acts as a mobility anchor for all 3GPP access systems. It functions as a GGSN toward SGSN. Although GGSN functions are mainly performed by the P-GW, this is not visible to the SGSN. The S-GW is controlled by the MME or SGSN, depending on the access network where the UE camps on (E-UTRAN or GERAN/UTRAN).

In order to support interworking, the MME needs to support signaling procedures with the SGSN. This is similar to the handover procedure supported by MME when MME relocation occurs. For interworking with legacy Gn/Gp-SGSN, the MME behaves like an SGSN.

1.9.3.4 Summary of Reference Points and Protocols

Table 1.5 summarizes the additional reference points and protocols used for interworking with 2G/3G networks.

1.12.2.1 Broadcast Multicast Service Center (BM-SC)

The Broadcast Multicast Service Center (BM-SC) includes functions for MBMS user service provisioning and delivery. It is the entry point for the content provider, used to authorize and initiate MBMS bearer services within the PLMN via SGmb interface and to schedule and deliver data transmissions via SGi-mb. The BM-SC authenticates, authorizes, and charges access requests from the content provider. The interface between BM-SC and content provider is not specified by 3GPP (except for Public Safety group calls, see Chapter 5).

1.12.2.2 MBMS Gateway (MBMS GW)

The MBMS Gateway delivers packets to eNodeBs in configured MBMS service areas via M1 interface and provides MBMS session control signaling (session start/stop/update) toward E-UTRAN (to the MCE) via the MME on Sm interface. The MBMS GW consists of a control and user plane part (MBMS CP and MBMS UP). The MBMS GW may be stand-alone or colocated with other network elements such as the BM-SC, S-GW, or P-GW. The Sn interface between MBMS GW and S4-SGSN is not shown in Figure 1.19. It provides control plane signaling similar to Sm and is used to forward MBMS data in point-to-point mode using GTP.

1.12.2.3 Multicell/Multicast Coordination Entity (MCE)

The Multicell/multicast Coordination Entity (MCE) provides functions for MBMS admission control and MBMS radio resource allocation. It interfaces with the eNodeBs in E-UTRAN via M2 interface. The MCE can be a stand-alone entity or colocated with an eNodeB, in which case only cells controlled by that particular eNodeB can form a MBSFN area (see next sections). In principle the MCE can also be colocated with the MBMS GW.

1.12.2.4 MME supporting MBMS

The MME is enhanced for MBMS to support MBMS session control signaling via M3 interface to the MCE. Not shown in the Figure 1.19 is the Mz interface between a BM-SC in HPLMN and a BM-SC in VPLMN (roaming case). Mz is currently supported for GPRS and UMTS only, but not for LTE/SAE.

1.12.2.5 UE supporting MBMS

The MBMS-capable UE needs to support additional functions for the activation and deactivation of the MBMS bearer service and special MBMS security functions (e.g., support of key distribution via the MICKEY protocol).

1.12.2.6 Summary of Reference Points and Protocols

Table 1.7 summarizes the reference points used for MBMS.