RNTI

In 3G UMTS the Radio Network Temporary Identifiers (RNTIs) are always used to identify information dedicated to a particular subscriber on the radio interface, especially if common or shared channels are used for data transmission. Now, in LTE it is the rule that common channels and shared channels are used to transmit all UE-specific data, but also some network-specific data across the radio interface. For this reason the RNTI in LTE is not always related to a particular subscriber, but sometimes also used to distinguish broadcast network information from data streams of subscribers.

The RNTI is signaled in the MAC layer.

When MAC uses the Physical Downlink Control Channel (PDCCH) to indicate radio resource allocation, the RNTI that is mapped on the PDCCH depends on the logical channel type:

• C-RNTI, Temporary Cell Radio Network Temporary Identifier (temp C-RNTI), and Semi-Persistent Scheduling (SPS) C-RNTI for Dedicated Control Channel (DCCH) and DTCH;
• Paging Radio Network Temporary Identity (P-RNTI) for Paging Control Channel (PCCH);
• Random Access Radio Network Temporary Identifier (RA-RNTI) for Random Access Response (RAR) on DL-SCH;
• Temporary C-RNTI for Common Control Channel (CCCH) during the random access procedure;
• System Information Radio Network Temporary Identifier (SI-RNTI) for Broadcast Control Channel (BCCH).

All RNTIs are encoded using the same 16-bit format (two octets = 2 bytes).

The following values (given in Table 1) are defined for the different types of RNTI.

Table 1: RNTI values (according to 3GPP 36.321). Reproduced with permission from © 3GPP™ 

Value (hexadecimal)		RNTI
FDD	TDD
0000-0009	0000-003B	RA-RNTI
000A-FFF2	003C-FFF2	C-RNTI, semi-persistent scheduling C-RNTI, temporary C-RNTI, TPC-PUCCH-RNTI, and TPC-PUSCH-RNTI
FFF3-FFFC		Reserved for future use
FFFE		P-RNTI
FFFF		SI-RNTI

1 P-RNTI

The P-RNTI is the 4G complement of the paging indicator known from 3G UMTS. It does not refer to a particular UE, but to a group of UEs.

The P-RNTI is derived from the IMSI of the subscriber to be paged and constructed by the eNB. For this reason the IMSI is transmitted in a S1AP paging message from the MME to eNB, although in other S1 signaling only the GUTI is used to mask the true identity of the subscriber.

2 RA-RNTI

The RA-RNTI is assigned by the eNB to a particular UE after this UE has sent a random access preamble on the Physical Random Access Channel (PRACH). If this random access preamble is received by the eNB and network access granted, the base station sends an acquisition indication back to the mobile and this acquisition indication message contains the RA-RNTI. In turn the UE will use the RA-RNTI to send a RRC connection request message on the radio interface UL and the parameter will help to distinguish messages sent by different UEs on the Random Access Channel (RACH).

3 C-RNTI

The C-RNTI is a 16-bit numeric value. Its format and encoding are specified in 3GPP 36.321 (MAC). The C-RNTI is part of the MAC Logical Channel Group ID field (LCG ID). It defines unambiguously which data sent in a DL direction within a particular LTE cell belongs to a particular subscriber. For instance, all RRC messages belonging to a single connection between a UE and the network are marked with the same C-RNTI value by the MAC entity that provided transport services to the RRC and NAS. Thus, C-RNTI is an important parameter for call tracing.

The C-RNTI comes in three different flavors: temp C-RNTI, semi-persistent scheduling C-RNTI, and permanent C-RNTI.

The temp C-RNTI is allocated to the UE during random access procedure (with a RRC connection setup message) and may turn into a permanent C-RNTI depending on the result of a subsequently performed contention resolution procedure or in the case of contention-free random access.

The semi-persistent scheduling C-RNTI is used if the subscriber is running services with a predictable unchanging QoS profile. A typical example is VoIP for which the required bit rate will not change during the entire connection. In such a case the dynamic (re)scheduling of radio resources, which is mandatory in the case of bursty payload traffic to ensure optimal usage of resource blocks, is not required. The SPS C-RNTI is used to indicate an area of resource blocks that will be used by the same UE for a longer time frame without any expected change.

4 SI-RNTI

The SI-RNTI is sent on the PDCCH. It does not stand for a particular UE identity. Instead it signals to all mobiles in a cell where the broadcast System Information Blocks (SIBs) are found on the Physical Downlink Shared Channel (PDSCH). This is necessary since the PDSCH is used to transport both broadcast system information for all UEs and signaling/payload for particular mobiles. In other words, the SI-RNTI indicates which DL resource blocks are used to carry SIBs that in 3G UMTS have been sent on the broadcast (transport) channel mapped onto the Primary Common Control Physical Channel (P-CCPCH). In LTE there is no CCPCH, only DL-SCH.

GUTI | Area and Subscriber Identities

The GUTI is assigned only by the MME during initial attach of a UE to the E-UTRAN.

The purpose of the GUTI is to provide an unambiguous identification of the UE that does not reveal the UE or the user's permanent identity in the E-UTRAN. It also allows identification of the MME and network to which the UE attaches. The GUTI can be used by the network to identify each UE unambiguously during signaling connections.

The GUTI has two main components: the Globally Unique Mobility Management Entity Identifier (GUMMEI) that uniquely identifies the MME which allocated the GUTI; and the M-TMSI that uniquely identifies the UE within the MME that allocated the GUTI. The GUMMEI is constructed from the MCC, MNC, and Mobility Management Entity Identifier (MMEI).

The MMEI should be constructed from a Mobility Management Entity Group ID (MMEGI) and a MMEC. The GUTI should be constructed from the GUMMEI and the M-TMSI as shown in Figure 1.

 

Figure 1: Format of GUTI and S-TMSI

For paging purposes, the mobile is paged with the S-TMSI. The S-TMSI is constructed from the MMEC and the M-TMSI. It is correct to say that the S-TMSI is a shorter format of GUTI that can be used because, after successful registration of a UE, the serving network as well as the serving MME group are known and stored in the core network databases.

The operator needs to ensure that the MMEC is unique within the MME pool area and, if overlapping pool areas are in use, unique within the area of overlapping MME pools.

The GUTI should be used to support subscriber identity confidentiality and, in the shortened S-TMSI form, to enable more efficient radio signaling procedures (e.g., paging and service request).

MCC and MNC should have the same field size as described for the IMSI.

The M-TMSI has a length of 32 bits, MMEGI is 16 bits in length, and MMEC 8 bits in length.

It is important to understand that on the S1 interface the IMSI is typically not seen, just like the GUTI. Exceptions are initial attach to the network when no old GUTI is stored on the USIM card or the true subscriber's identity is checked using NAS signaling, which regularly happens when roaming subscribers attach. Also, in the case of the paging procedure the IMSI might be seen.

For monitoring and network performance measurement the IMSI on S1 can only be revealed if the changing temporary identities are tracked with a quite sophisticated architecture. Full IMSI tracking can only be ensured by monitoring all S1 interfaces of an operator's E-UTRAN and ideally all S6a interfaces and storing the current GUTI/IMSI relations in a central point as stored in the HSS.

LMSI, TMSI, P-TMSI, M-TMSI, and S-TMSI | Area and Subscriber Identities

All temporary subscriber identities, Local Mobile Subscriber Identity (LMSI), TMSI, and P-TMSI, will not be seen in E-UTRAN signaling as long as there is no inter-RAT mobility between the E-UTRAN and UTRAN/GERAN. Indeed, for LTE a new NAS protocol was specified (3GPP 24.301) that introduces a new temporary subscriber identity for the E-UTRAN: the GUTI described in Section 1.4.4. However, to fulfill inter-RAT mobility requirements TMSI, P-TMSI, and LMSI will still be found in E-UTRAN NAS messages, or at least it will be indicated if valid values of these parameters are stored on the USIM card.

The LMSI is a four-octet/byte number. It is a pointer to a database record for a particular IMSI in the Visitor Location Register (VLR) database. Although the VLR is no longer found in the EPC network architecture, there is a database with the same function hosted by the MME. The purpose of the LMSI was to speed up the search for particular database records. If this is still required, with the new powerful computer hardware used to build today's network elements it is a design detail to be defined by NEMs. From definitions given in 3GPP 23.003 it can be guessed that the LMSI will not be used by the MME.

The TMSI is also encoded as a four-octet/byte hex number. It is allocated to a particular subscriber (more correctly, to a particular subscriber's (U)SIM card) during initial attach. The TMSI is used to mask the true subscriber's identity, which is the IMSI, in NAS signaling procedures. In the E-UTRAN it is often used together with the GUTI. It can be coded using a full hexadecimal representation. Since the TMSI has only local significance (i.e., within a VLR and the area controlled by a VLR, or within a SGSN and the area controlled by a SGSN, or within a MME and the area controlled by a MME), the structure and coding of it can be chosen by agreement between the operator and manufacturer in order to meet local needs.

The TMSI allocation procedure should always be executed in ciphered mode to prevent unauthorized eavesdropping.

The P-TMSI is the complement of TMSI in the UTRAN/GERAN PS domain. It is allocated by the SGSN and, hence, will be monitored in the EPC and E-UTRAN during inter-RAT handover/relocation preparation and execution. The P-TMSI is encoded in the same way as the TMSI. The difference is in defining value ranges. If the first two leading digits have the value "11" the parameter is identified as a P-TMSI. Thus, in the hexadecimal format, all TMSI values starting with C, D, E, or F as the first hex number are P-TMSIs.

The M-TMSI is a 32-digit binary number that is part of the GUTI and exclusively used in the E-UTRAN.

The S-TMSI consists of the Mobility Management Entity Code (MMEC) and M-TMSI. Indeed, it is just a shorter variant of the GUTI.

IMSI | Area and Subscriber Identities

The IMSI allows unambiguous identification of a particular SIM or USIM card. The IMSI is composed of three parts (Figure 1):

• The Mobile Country Code (MCC), consisting of three digits. The MCC uniquely identifies the country of domicile of the mobile subscriber. MCC values are administrated and allocated 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 and is beyond the scope of this specification.
• 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 Signaling Connection Control Part (SCCP) Global Title translation procedures when roaming subscribers register in foreign networks.
  
  

 

Figure 1: Structure of IMSI (according to 3GPP 23.303). Reproduced with permission from © 3GPP™

The National Mobile Subscriber Identity (NMSI) consists of the MNC and the MSIN.

A combination of MCC and MNC can be used to aggregate call-specific performance measurement data (such as cumulative counters) on IMSI groups. This will help to highlight problems of roaming subscribers such as network failures during registration procedures, as described later in this book. Table 1 shows some samples from an IMSI group mapping table with MCC/MNC combinations in "IMSINumber" fields and operator names in the "IMSIGroupName" field. Note the three-digit MNC used for the American operator.

Table 1: IMSI group mapping table from Tektronix Communications NSA software

<IMSI IMSINumber= ‘26201’ IMSIGroupName= ‘T-MOBILE DEUTSCHLAND GMBH (GERMANY)’ />

<IMSI IMSINumber= ‘26202’ IMSIGroupName= ‘VODAFONE D2 GMBH (GERMANY)’ />

<IMSI IMSINumber= ‘26801’ IMSIGroupName= ‘VODAFONE TELECEL (PORTUGAL)’ />

<IMSI IMSINumber= ‘27201’ IMSIGroupName= ‘VODAFONE IRELAND PLC (IRELAND)’ />

<IMSI IMSINumber= ‘310560’ IMSIGroupName= ‘T-MOBILE USA, INC. (UNITED STATES)’ />

It is possible that one-use equipment will work with more than just one (U)SIM. A good example is a mobile phone that has both business and private SIM cards as one device. Depending on the nature of the call (private or business), the owner of the handset can choose which (U)SIM should be used to make the call. Such a procedure might be required in case private phone calls need to be charged separately due to national income tax laws (as found, for example, in Germany).

Domains and Strati | Area and Subscriber Identities

For the EPC a complete new NAS was designed including a new NAS protocol layer described in 3GPP 24.301.

In contrast to the core network of 3GPP Release 99 to Release 6 where a CS and PS domain were defined as subdomains of the serving network domain, the EPC will not host any CS domain due to its all-IP character. However, it still distinguishes between AS and NAS signaling and functions as shown in Figure 1.

 

Figure 1: Domains and strati in E-UTRAN and EPC

The AS comprises the radio chipset of the UE including the RRC protocol entity and all underlying transport layer entities. Here all parameters that more or less frequently change during radio access can be found, including transport formats and radio-specific identities of serving cell and possible handover candidates (neighbor cells).

The NAS covers all signaling exchanged between the USIM (UMTS Subscriber Identity Module) and the core network node, in case of LTE radio access: the MME. This is the home of all parameters that allow unambiguous identification of a subscriber or the handset hardware such as International Mobile Subscriber Identity (IMSI) and International Mobile Equipment Identity (IMEI). There are also temporary identities stored on the USIM card like Temporary Mobile Subscriber Identity (TMSI) and Globally Unique Temporary UE Identity (GUTI). From a protocol point of view the NAS is the home of network access, initial subscriber registration, and mobility management procedures. Due to the all-IP concept of LTE/EPC, a new NAS protocol was defined, namely 3GPP 24.301, while similar functions for 2G/3G networks are defined in the standard 3GPP 24.008. The E-UTRAN NAS protocol 3GPP 24.301 does not contain any functions for CS call control and SMS. In the early planning stages of the E-UTRAN it was assumed that all speech services via the E-UTRAN would use VoIP and the IMS architecture. As an alternative the CS fallback option (implemented in the S1AP protocol) was designed, but obviously this did not satisfy the need for reliable and cost-efficient CS services in the E-UTRAN. Hence, an initiative formed of operators and Network Equipment Manufacturers (NEMs) started to work on the Voice over LTE via Generic Access standards (VoLGA). VoLGA is beyond the scope of 3GPP. Its principle is to establish an IP connection between the UE and E-UTRAN and use the radio bearer for transparent forwarding of 3GPP 24.008 NAS signaling message and AMR (Adaptive Multirate) voice packets across the logical Z1 interface. Instead, in the S-GW the RAB used for VoLGA is terminated in a special protocol converter and media gateway device, the VoLGA Access Network Controller (VANC), that is, the interconnecting point between the E-UTRAN/EPC and UTRAN/GERAN/Legacy Core Network.

Interfaces and Reference Points

As already explained, the E-UTRAN is an all-IP network. Figure 1 shows the network elements that are typically involved in the signaling procedures and routing of payload data from the UE to the PDN and vice versa. The figure also shows the reference points for inter-RAT handover (and inter-RAT packet routing) between E-UTRAN, UTRAN, and GERAN.

The pipeline symbols in the figure illustrate the different signaling connections and tunnels for IP payload transport established and maintained during the connection. The signaling on Gx and Rx used to negotiate specific QoS policies is ignored for reasons of better understandability. Besides, the existence of the PCRF is optional. Due to the fact that the MME and the S-GW may also be combined into a single physical entity, the S11 interface is also optional. The lab test scenarios existing at the time of writing (spring 2010) all have separated physical entities for the MME and S-GW.

The signaling connection across the LTE-Uu interface is the RRC signaling connection, represented by a set of Signaling Radio Bearers (SRBs). The user plane tunnel across LTE-Uu is the radio bearer. The other user plane tunnels are named after the appropriate reference points: namely, S1 bearer and S5 bearer. After the PDN-GW the connection is carried by the external bearer on SGi. S1AP signaling between the E-UTRAN and MME will be used to establish the tunnel on S1-U and GTP-C signaling will be used to create the tunnel on S5. On SGi we can see already plain IP traffic – pure payload, so to say.

The reference points can be briefly described as follows:

• S1-MME: Reference point for the control plane protocol between the E-UTRAN and MME. This control plane protocol is the S1AP, which is quite similar to UTRAN RANAP. Indeed, in early drafts of LTE specs this protocol was called "E-RANAP."
• S1-U: Reference point between the E-UTRAN and S-GW for the per bearer user plane tunneling and inter-eNB path switching during handover. The protocol used at this reference point is the GPRS Tunneling Protocol for the User Plane (GTP-U).
• S3: This is the reference point between the MME and SGSN. The SGSN may serve UTRAN, GERAN, or both. On S3 we can see plain control plane information for user and bearer information exchange for inter-3GPP access network mobility (inter-RAT handover) in the idle and/or active state. If the connection was set up originally in the E-UTRAN and is handed over to UTRAN/GERAN the appropriate user plane streams are routed across the S4 reference point. What happens in the case of UTRAN/GERAN to E-UTRAN handover depends on whether S-GW also acts as the anchor for UTRAN/GERAN traffic. If this is true the user plane tunnel can be switched smoothly between S4 and S1-U during the handover. The protocol used at the S3 reference point is the GTP-C.
• S4: The S4 reference point provides related control and mobility support between the GPRS core and the 3GPP anchor function of the S-GW using GTP-C. In addition, if a direct tunnel across S12 is not established, it provides user plane tunneling using GTP-U.
• S5: The S5 reference point provides user plane tunneling and tunnel management between the S-GW and PDN-GW. It is used in case of S-GW relocation due to UE mobility and if the S-GW needs to connect to a non-collocated PDN-GW for the required PDN connectivity. The protocol used at this reference point is GTP for both the control plane and user plane.
• S6a: The S6a reference point enables the transfer of subscription and authentication data for authorizing user access to the network. The reference point can be also described as the AAA interface between the MME and HSS. Compared to the legacy core network of 2G/3G standards, the functionality provided by S6a is similar to the one on the Gr interface, but due to the all-IP concept of EPC the protocol used at this reference point is the DIAMETER protocol. In the IP world DIAMETER is known as the successor of RADIUS, a protocol for granting access and authentication. However, the DIAMETER used on S6a does not have much in common with what is found in the IP world. The protocol header is based on IP standards, but the messages and parameters on the application layer are defined in a 3GPP-specific DIAMETER standard that has no meaning in the IP world.
• Gx: This point provides transfer of (QoS) policy and charging rules from the PCRF to the Policy and Charging Enforcement Function (PCEF) in the PDN-GW. This means that a set of rules for charging the transmission of a particular user data stream (called service flow) will be requested by the PDN-GW upon bearer establishment and the PCRF will provide the required parameters for the charging process. Especially, it will signal which of the following charging models will apply:
  • – Volume-based charging.
  • – Time-based charging.
  • – Volume-and time-based charging.
  • – Event-based charging.
  • – No charging (if the user pays at a monthly flat rate).
  • Also, information about prepaid limits and other thresholds can be included.
• S8: The S8 reference point is used by roaming subscribers only. It is the inter-PLMN reference point providing the user plane and control plane between the S-GW in the Visited PLMN (VPLMN) and the PDN-GW in the Home PLMN (HPLMN). S8 is the inter-PLMN variant of S5, based on GTP as well, and can be compared to the Gp interface defined for GERAN GPRS.
• S8: The S8 reference point is also used by roaming subscribers only. It provides transfer of (QoS) policy and charging control information between the home PCRF and the visited PCRF in order to support the local breakout function. For example, imagine a prepaid limit that can only be known by the home PCRF and must be provided to the visited PCRF to allow roaming services for this user.
• S10: This is the reference point between MMEs for MME relocation and MME-to-MME information transfer. This reference point provides mobility functions for intra-E-UTRAN handover/relocation. In other words, signaling procedures on this interface are triggered by UE mobility. It should be noted that this kind of MME relocation in 3GPP 23.401 is called S1 handover. Hence, S10 is seen as special kind of S1 interface and the S1AP is used at this reference point.
• S11: This is the reference point between the MME and S-GW. The protocol used here is the GTP-C. The appropriate user plane is routed across S1-U.
• S12: The S12 reference point is located between the RNC in the 3G UTRAN and the S-GW for user plane tunneling when a "direct tunnel" is established. It is based on the Iu user plane and Gn user plane reference points using the GTP-U as defined between the SGSN and RNC, or between the SGSN and GGSN in the 3G core network. Use of the S12 reference point is an operator configuration option. On S12 only GTP-U traffic can be monitored, as on S1-U.
• S13: This point enables a UE identity check procedure between the MME and EIR (Equipment Identity Register). Typically there is no EIR installed in public networks due to the high administrative efforts, but this network element is found in some private networks. For instance, the GSM-based mobile network of the railway company Deutsche Bahn is equipped with an EIR. The purpose is to ensure that only staff of Deutsche Bahn can use the company's PLMN, but no private persons and staff of other European railway companies such as France's SNCF that also runs trains through Germany.
• SGi: This is the reference point between the PDN-GW and the packet data network. This network may be an operator external public or private packet data network or an intra-operator packet data network, for example for the provision of IP Multimedia Subsystem (IMS) services. To simplify the definition, it can be said that for many user plane connections SGi is the interface to the public Internet. This reference point corresponds to Gi for 3GPP access. Typically the complete TCP/IP suite can be monitored at this point.
• Rx: The Rx reference point resides between the Application Function (AF) and the PCRF defined in 3GPP 23.203. It is for instance mandatory if real-time communication services such as Voice over IP (VoIP) are to be charged differently than common PS data transfer.
• SBc: The SBc reference point lies between the Cell Broadcast Center (CBC) and MME for warning message delivery and control functions. This interface is used to broadcast warning messages to subscribers (not to send warning messages about network element status to the operation and maintenance center). A typical example of such warning messages could be the broadcast of bush fire or tsunami alarms.
  
  

 

Figure 1: Connection via E-UTRAN non-roaming architecture

 

Figure 2: Connection after inter-RAT handover from E-UTRAN to UTRAN/GERAN

 

Figure 3: Connection via E-UTRAN with roaming in EPC

The special anchor function of the S-GW can be illustrated when looking at a connection that was handed over from the E-UTRAN to UTRAN or GERAN as shown in Figure 1.12. In this case the connections on S5 and SGi remain the same, but the payload is now routed through a tunnel across S4 or S12 while the signaling necessary to execute the inter-RAT mobility will be sent across S3. The old bearers and signaling connections on S1 and LTE-Uu will be deleted after successful handover of the connection.

Figure 1.13 illustrates the basic connection of a roaming subscriber. Signaling and payload take the same route as in Figure 1.12, but the HSS and PDN-GW and, thus, the connection to the public packet network are located in a foreign network. The IP tunneling from the S-GW to PDN-GW and vice versa is realized through the S8 interface, which has identical protocol structure and functions to S5. The only difference is that S8 must fulfill higher requirements in terms of inter-operability, because equipment from different manufacturers must be interconnected through this reference point.

Packet Data Network Gateway (PDN-GW)

The PDN-GW provides access from the mobile operator's network to the PS networks that host the payload contents and operator's IP services. If a user has access to more than one packet data network it is possible that this user is connected to more than just one PDN-GW. It is not possible for the same UE to simultaneously open connections to a PDN-GW and to a GGSN in the 3G PS domain, according to 3GPP standards.

The main function of the PDN-GW is to establish, maintain, and delete GTP tunnels to S-GW or SGSN in the case of inter-RAT mobility scenarios. The PDN-GW allocates the user's dynamic IP addresses and routes the user plane packets. In addition, it provides functions for lawful interception, policy/QoS control, and charging.

For policy control and charging, the PDN-GW can be connected to a Policy and Charging Rule Function (PCRF) via the Gx reference point. The PCRF provides guidance on how a particular service data flow should be treated in terms of priority, throughput, and other QoS parameters according to the user's subscription profile.

Serving Gateway (S-GW) | Network Elements and Functions

The S-GW is the gateway which terminates the interface to the E-UTRAN. A particular LTE subscriber will always be connected by a single S-GW.

In the case of inter-eNB handover, the S-GW acts as the mobility anchor of the connection and remains the same while the path for the transport of signaling and user plane will be switched onto the S1 interface. Once a handover is executed successfully and the associated UE has left the S-GW, the old S-GW will send one or more "end marker" packets to the source eNB, source SGSN, or source RNC of the handover to assist the reordering of user plane packets in these network elements.

Mobility anchoring of the S-GW is also defined for inter-3GPP mobility. Here the S-GW acts as the terminating point of the S4 interface and routes the traffic between the 2G/3G SGSN and the PDN-GW of the EPC. In other words, when it comes to inter-RAT handover involving the S4 interface, the S-GW acts as the Gateway GPRS Support Node (GGSN) (of the 2G/3G PS core network) that enables usage of the EPC transport and functions for UTRAN/GERAN PS services.

If the UE is in ECM-IDLE mode the S-GW buffers user plane packets that will be sent to the UE after a successful paging response. The paging via the S1 and Uu interfaces is also triggered by the S-GW.

The S-GW is the network element that provides connectivity and software implementations for lawful interception.

On the IP transport layer the S-GW acts as a packet router. User plane packets are forwarded transparently in the UL and DL direction and their underlying transport units are marked by S-GW with parameters like DiffServ Code Point, based on the QoS Class Indicator (QCI) of the associated EPS bearer.

Also embedded in the S-GW software are various charging functions for UL and DL charging per UE, PDN, and QCI. These functions are used to charge the operator's own subscribers as well as roaming users (inter-operator charging).

The S-GW can be connected to SGSNs in non-roaming and roaming scenarios. However, connectivity to a GGSN is not supported.

Mobility Management Entity (MME) | Network Elements and Functions

The MME is responsible for the NAS connection with the UE. All NAS signaling messages are exchanged between the UE and MME to trigger further procedures in the core network if necessary.

A new function of the E-UTRAN is NAS signaling security. The purpose of this feature is to protect the signaling messages that could reveal the true subscriber's identity and location from unauthorized eavesdropping.

The MME is also responsible for paging subscribers in the EPS Connection Management (ECM) IDLE state (including control and execution of paging retransmission) and is concerned with tracking area list management. The list of tracking areas is the list of locations where the UE will be paged.

To route the user plane data streams the MME will select the best fitting PDN-GW and S-GW. It will also connect the E-UTRAN with the 3G UTRAN using the S3 interface (MME to SGSN). When necessary, a relocation of gateways will be triggered and controlled by the MME.

As its name suggests, the MME will perform management of handovers by selecting a new (target) MME or SGSN for handovers to 2G or 3G 3GPP access networks. Also, it is the MME that hosts the connection to the HSS across the S6a interface and, hence, it is responsible for roaming management and authentication of subscribers.

Last but not least, the MME sets up, modifies, and releases default and dedicated bearers. This function is commonly known as the bearer management function.

According to standard documents, the MME will allow lawful interception of signaling traffic and transfer of warning messages (including selection of an appropriate eNB). The purpose of warning message transfer is to inform people living in a larger area about upcoming natural disasters like storms, bush fires, or tsunamis.