LTE Security | Standards, Protocols, and Functions

What are the new security functions in the E-UTRAN? This question can briefly be answered as follows.

The first feature we see is a completely new ciphering mechanism and integrity protection for NAS signaling messages that was never seen in any 2G or 3G radio access network. On the radio interface this new NAS security leads to situations with double ciphering. On top of the protocol stack the NAS messages exchanged between the UE and MME are encrypted and the underlying RRC that acts as the transport layer for NAS is secured by ciphering mechanisms as well, so that the ciphered NAS message is ciphered together with its RRC transport message a second time.

The second new security feature is the option to secure the complete IP-based transport of the control plane and user plane on the S1 reference point using Secure IP (IPsec). There is no way to decipher IPsec by just monitoring the data that is exchanged between two endpoints of an IPsec connection. To decipher IPsec requires the monitoring software to be informed about which IPsec ciphering parameters (which can be changed frequently) are currently used in each of the involved endpoints of the IP connection. In a typical case these endpoints are the eNB and the MME or S-GW. To allow deciphering, there must be a dedicated Application Programming Interface (API) installed that allows the monitoring software to access IPsec-relevant parameters for deciphering. To design such an API requires close cooperation between the NEMs of eNB and MME/S-GW and the manufacturers of the monitoring software. The conclusion related to this fact is that free-of-charge monitoring software like WireShark will not be able to decipher IPsec. However, to obtain statistics of S1 control plane and user plane performance it is crucial to have metrics for E-UTRAN QoS and QoE (Quality of Experience). Consequently, IPsec deciphering will become one of the key differentiators for E-UTRAN monitoring software.

Besides these new security features, all the security elements from previous standards such as mutual authentication and masking of subscriber identity by using temporary identities can be found in the E-UTRAN. There is only a minor change here: the TMSI will be replaced by the new GUTI parameter.

To understand how the overall LTE security concept works, it is crucial to understand the hierarchy of LTE security keys first. This LTE security key hierarchy, shown in Figure 1, includes the following keys: K_eNB, K_NASint, K_NASenc, K_UPenc, K_RRCint, and K_RRCenc:

• K_eNB is a key derived by the UE and MME from K_ASME or by the UE and target eNB from Ke_NB* during eNB handover. K_eNB should only be used for the derivation of keys for RRC traffic and the derivation of keys for UP (User Plane) traffic, or to derive a transition key K_eNB* during an eNB handover.
  
  

Figure 1: LTE security key hierarchy (according to 3GPP 33.401). Reproduced with permission from © 3GPP™

Keys for NAS traffic:

• KNASint is a key which should only be used for the protection of NAS traffic with a particular integrity algorithm. This key is derived by the UE and MME from Kasme, as well as an identifier for the integrity algorithm.
• KNASenc is a key which should only be used for the protection of NAS traffic with a particular encryption algorithm. This key is derived by the UE and MME from Kasme, as well as an identifier for the encryption algorithm.

Keys for UP traffic:

• K_UPenc is a key which should only be used for the protection of UP traffic with a particular encryption algorithm. This key is derived by the UE and eNB from K_eNB, as well as an identifier for the encryption algorithm.

Keys for RRC traffic:

• K_RRCint is a key which should only be used for the protection of RRC traffic with a particular integrity algorithm. K_RRCint is derived by the UE and eNB from K_eNB, as well as an identifier for the integrity algorithm.
• K_RRCenc is a key which should only be used for the protection of RRC traffic with a particular encryption algorithm. K_RRCenc is derived by the UE and eNB from K_eNB as well as an identifier for the encryption algorithm.

Now, whenever a call is established the security functions will work as shown in Figures 2–4. The start trigger of the security functions is when an initial NAS signaling message sent by the UE that contains UE security capability information arrives at the MME. The security capability list informs the MME for instance about which ciphering and integrity protection algorithms are supported by this UE.

Figure 2: Subscriber authentication

Figure 3: NAS security initiation and RRC security initiation

Figure 4: RRC security completion

After the MME has received the initial NAS message and it has not been in contact with this subscriber before, or if all previously received security tokens sent by the HSS have been used, the MME must contact the HSS to receive new tokens. Thus, the MME sends a DIAMETER authentication information request message to the HSS that contains the subscriber's identity. The HSS holds the secret network key "K" that is also stored on the USIM card of each subscriber. "K" is unique to every network operator.

From "K" and the subscriber's identity the HSS derives three of the four parameters found inside the DIAMETER authentication information response message: the security key K_ASME, the Authentication Token (AUTN), and the Expected Response (XRES) parameter. The random number parameter RAND is truly just a random number.

After the MME has received these four parameters, it produces three more derivatives from K_ASME. These derivatives are the NAS encryption key K_NASenc, the NAS integrity protection key K_NASint, and the security key for the eNB K_eNB.

What follows is the authentication procedure between the MME and the UE. The MME sends the unciphered NAS authentication request message that includes the random number RAND and the AUTN. Now the UE must use its secret key "K" from the USIM card to calculate another number based on "K," AUTN, and RAND. The number is the UE's authentication response number RES.

RES is sent back to the MME by using the authentication response message, and in the last step of the authentication procedure the MME compares the value of RES to the value of XRES, which is the XRES value computed previously by the HSS. If RES and XRES have the same value the UE has successfully authenticated itself to the network and the NAS signaling connection can proceed.

At this point, after successful authentication, it is time to activate the NAS security functions: namely, NAS ciphering and NAS integrity protection. Thus, the MME sends the NAS security mode command message to the UE including the security key Kasme received previously from the HSS, and the algorithms for EPS encryption and EPS integrity protection that have been selected from the UE capability list and will be used to secure this NAS signaling connection.

After the UE has received the NAS security command, it computes on behalf of the assigned EPS encryption/integrity algorithms and the Kasme key the keys for NAS encryption and NAS integrity protection that are identical to those already stored in the MME. Now NAS security is in service the UE sends back the NAS security mode complete message, which is the encrypted and integrity protected NAS message. It is not mandatory to use NAS encryption and integrity protection. It is always up to the operator to decide what is required to secure the network.

After the NAS security functions are in service, the underlying RRC connection and the ciphering for user plane traffic need to be activated. For this purpose, first a so-called security context is installed between the MME and eNB. Since security is not the only context-related information to be exchanged between these two network elements, the S1AP initial context setup message will also contain other parameters besides the UE security capabilities and the eNB's security key K_eNB. Note that the UE security capabilities so far are unknown to the eNB.

Now the eNB derives the keys for RRC encryption (K_RRCenc), RRC integrity protection (K_RRCint), and user plane encryption (K_UPenc) from K_ASME. Then the eNB sends the RRC security mode command message to the UE. This message contains the AS encryption algorithm and AS integrity protection algorithm bundled with the START parameters for the AS security activation procedure.

The UE computes the keys for RRC encryption (K_RRCenc), RRC integrity protection (K_RRCint), and user plane encryption (K_UPenc) from the K_ASME together with the received keys and activates the requested security functions using these parameters. After successful activation, the UE sends the RRC security mode complete message (i.e., ciphered and/or integrity protected) back to the eNB. And the eNB confirms the successful establishment of the security context to the MME by sending the S1AP successful outcome message for the procedure code "Initial Context Setup."

QoS Architecture | Standards, Protocols, and Functions

The EPS bearer service layered architecture is depicted in Figure 1. Besides the different names of bearers and reference points, this architecture does not look very different from the bearer service architecture defined in Release 99. However, there is a major difference that is not obvious at first sight.

 
Figure 1: LTE QoS architecture (according to 3GPP 23.401). Reproduced with permission from © 3GPP™

In 3G UMTS the request of a subscriber for a defined QoS of an end-to-end service starts the QoS negotiation procedure. This depends on the subscriber's subscribed QoS stored in the HLR and the available network resources which QoS is granted to a particular connection at the end. The QoS negotiation and control process starts on the NAS layer with the first SM message sent by the UE.

In LTE – different to 2.5 and 3G PS connections – a default bearer with a default QoS is already established when the UE attaches to the network. The QoS attributes of this default bearer are determined by the subscribed QoS parameters stored in the HSS. This is still as seen in 2.5/3G networks.

However, if now the first user plane packet is sent by the UE it is routed toward the PDN where the PCRF analyzes the requested end-to-end service. Depending on this service, the PCRF may now trigger a modification of QoS parameters in all the involved bearers. There is no option for the subscriber to request a particular QoS; only the network is in charge of QoS control. There is also no way for the UE to request something known as a secondary context in 3G (see Section 3.26 in Kreher and Ruedebusch, 2007). In LTE all QoS management is tied to the application, not to SM signaling.

It is important to understand that one UE in LTE can have multiple end-to-end services active and each of these services will have its own individual bearer. It is not intended by LTE standards that, for example, non-real-time services like web-browsing and e-mail will be mapped onto the same bearer (e.g., the same S1-U GTP tunnel) as we have seen in 3G UMTS. For this reason also 256 individual E-RABs for a single UE can be addressed by E-UTRAN protocols while in UMTS only 15 different RAB-IDs had been defined by the standard organizations.

In the 3GPP specs there is also a Traffic Flow Template (TFT) mentioned for the UL as well as for the DL part of the connection. These TFTs are bound to the EPS bearers. In general, a TFT can be described as a set of filters for a particular end-to-end service. Each TFT consists of a destination IP address and a set of source/destination port numbers. On the DL, the IP address is the address assigned to the UE; on the UL, it is the address of a server on the PDN. If we assume, for example, an HTTP 1.1 end-to-end service, the DL TFT of this service consists of the UE's IP address, the TCP source port number is 80, and the TCP destination port number is 80. On the UL, the port numbers are the same, but the IP address is the address of the server that hosts the web site.

To standardize the QoS handling, a set of nine QCIs have been defined by 3GPP. There are four classes with a Guaranteed Bit Rate (GBR) and five classes with a Non-Guaranteed Bit Rate (Non-GBR).

Besides the bit rate, the parameter priority, packet delay budget, and packet error loss rate are critical factors as given in Table 1.

Table 1: Standardized QCI, QoS parameter thresholds, and example services (according to 3GPP 23.203). Reproduced with permission from © 3GPP™ 

QCI	Resource type	Priority	Packet delay budget (ms)	Packet error loss rate	Example services
1	GBR	2	100	10−2	Conversational voice
2		4	150	10−3	Conversational video (live streaming)
3		3	50	10−3	Real-time gaming
4		5	300	10−6	Non-conversational video (buffered streaming)
5	Non-GBR	1	100	10−6	IMS signaling
6		6	300	10−6	Video (buffered streaming) TCP based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)
7		7	100	10−3	Voice, video (live streaming) interactive gaming
8		8	300	10−6	Video (buffered streaming) TCP based
9		9			(e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)

User Equipment

As in UMTS, the LTE mobile station is called User Equipment (UE). It is constructed using a modular architecture that consists of three main components (see Figure 1):

• Mobile Termination: The MT represents termination of the radio interface. In this entity the RRC signaling is terminated and RRC messages are sent/received.
• Terminal Adapter: The terminal adapter represents the termination of the application-specific service protocols, for example, SIP signaling for VoIP. The terminal adapter might be constructed as an external interface, for example, USB to connect a laptop PC using LTE technology with a mobile network.
• Terminal Equipment: The TE represents termination of the service. Depending on the UE's application capabilities, it may act as the TE or not. For instance, the Apple iPhone with its browser functionalities has full TE capability while a simple USB stick for mobile data transmission has no TE capability at all. In the case of the USB stick, the connected laptop PC is the TE.
  
  

 
Figure 1.: Modular architecture of a UE

1) UE Categories

The UE categories stand for an abstract grouping of common UE radio access capabilities and are defined in 3GPP 36.306.

In particular, the handset-type groups vary in maximum possible throughput (the maximum number of DL-SCH transport blocks bits received within a Time Transmission Interval (TTI)). Assuming a TTI of 1 ms for category 1, the maximum possible throughput is 10 296 bits/1 ms which is approximately 10Mbps of physical layer DL throughput (including the RLC/MAC header information-so the payload throughput will be slightly less).

Category 5 mobiles are the only handsets that support 64 Quadrature Amplitude Modulation (QAM) on the UL as highlighted in Tables 1 and 2. The maximum possible bit rate ranges from 5 Mbps (Cat. 1) to 75 Mbps (Cat. 5).

Table 1: UE categories and DL capabilities (according to 3GPP 36.306). Reproduced with permission from © 3GPP™ 

UE category	Maximum number of DL-SCH transport block bits received within a TTI	Maximum number of bits of a DL-SCH transport block received within a TTI	Approximate maximum bit rate DL (Mbps)
Category 1	10 296	10 296	10
Category 2	51 024	51 024	50
Category 3	102 048	75 376	75
Category 4	150 752	75 376	75
Category 5	302 752	151 376	150

Table 2: UE categories and UL capabilities (according to 3GPP 36.306). Reproduced with permission from © 3GPP™ 

UE category	Maximum number of bits of an UL-SCH transport block transmitted within a TTI	Support for 64QAM in UL	Approximate maximum bit rate UL (Mbps)
Category 1	5 160	No	5
Category 2	25 456	No	25
Category 3	51 024	No	50
Category 4	51 024	No	50
Category 5	75 376	Yes	75

Access Point Name

In the GPRS backbone, an Access Point Name (APN) is a reference to a GGSN. To support inter-PLMN roaming, the internal GPRS DNS (Domain Name System) functionality is used to translate the APN into the IP address of the GGSN.

In the EPC network the APN is found in GTP-C signaling when packet contexts are established, but it is no longer found in LTE NAS signaling. This means in turn that for 2.5G and 3G phones the APN is an important parameter to be stored on the (U)SIM card, but for 4G phones the APN does not need to be configured by the end user. This will also resolve the problem where many PDP context setup failures seen currently in the GERAN and UTRAN are due to an unknown or missing APN.

The APN is composed of two parts as follows:

• The APN network identifier; this defines to which external network the GGSN is connected and optionally a requested service by the MS. This part of the APN is mandatory.
• The APN operator identifier; this defines in which PLMN GPRS backbone the GGSN is located. This part of the APN is optional.

The APN operator identifier is placed after the APN network identifier. An APN consisting of both the network identifier and operator identifier corresponds to the DNS name of a GGSN; the APN has, after encoding as defined below, a maximum length of 100 octets.

The encoding of the APN follows the name syntax defined in RFC 2181 [18], RFC 1035 [19], and RFC 1123 [20]. The APN consists of one or more labels. Each label is coded as a one-octet length field followed by that number of octets coded as 8-bit ASCII characters. Following RFC 1035 [19], the labels should consist only of the alphabetic characters (A–Z and a–z), digits (0–9), and the hyphen (-). Following RFC 1123 [20], the labels should begin and end with either an alphabetic character or a digit. The case of alphabetic characters is not significant. The APN is not terminated by a length byte of zero.

Typical APNs are:

• mms.tim.net;
• wap.eplus.net;
• wap.beeline.ru;
• wap.debitel.de;
• web.vodafone.de;
• internet.t-mobile.

The APN of a 3G subscriber is stored in the USIM. In LTE NAS signaling the APN is no longer used, because it is chosen by the intelligent packet routing functions of MME. However, the APN Average Maximum Bit Rate (APN-AMBR) may be signaled to the UE by the MME to control the amount and bandwidth of UL traffic.

Mapping between Temporary and Area Identities for EUTRAN- and UTRAN/GERAN-Based Systems

For the construction of the RA update request message in GERAN/UTRAN or TA update request message in E-UTRAN the following identities should be included.

In GERAN and UTRAN the RAI is constructed from the MCC, MNC, LAC, and RAC. In addition, the routing area update request message contains the P-TMSI that includes the mapped Network Resource Identifier (NRI) that is used in Iu flex networks. (An example of NRI usage is given in Kreher and Ruedebusch, 2007.)

P-TMSI should be of 32-bit length where the two topmost bits are reserved and always set to 11. These are needed since the GERAN representation of P-TMSI, of the form TLLI (Temporary Logical Link Identity), imposes this restriction. Hence, for a UE which may hand over to GERAN/UTRAN (based on subscription and UE capabilities), the corresponding bits in the M-TMSI are set to 11.

The NRI field is of variable length and should be mapped into the P-TMSI starting at bit 23 and down to bit 14. The most significant bit of the NRI is located at bit 23 of the P-TMSI regardless of the configured length of the NRI.

In the case of a combined MME-SGSN node, the NRI of the SGSN part and the MMEC of the MME part refer to the same combined node. The RAN configuration allows NAS messages on GERAN/UTRAN and E-UTRAN to be routed to the same combined node. The same or different values of NRI and MMEC may be used for a combined node.

The mapping of the GUTI should be done to a combination of the RAI of GERAN/UTRAN and the P-TMSI as follows:

E-UTRAN <MCC>	maps to GERAN/UTRAN <MCC>
E-UTRAN <MNC>	maps to GERAN/UTRAN <MNC>
E-UTRAN <MME Group ID>	maps to GERAN/UTRAN <LAC>
E-UTRAN <MME Code>	maps to GERAN/UTRAN <RAC>

It is also copied into the eight most significant bits of the NRI field within the P-TMSI. E-UTRAN <S-TMSI> maps as follows:

• 22 bits of the E-UTRAN <M-TMSI> starting at bit 30 and down to bit 9 are mapped into the remaining 22 bits of the GERAN/UTRAN <P-TMSI>;
• the remaining 8 bits of the E-UTRAN <M-TMSI> are copied into 8 bits of the <P-TMSI signature> field.

For the UTRAN, the 10-bit-long NRI bits are masked out from the P-TMSI and also supplied to the RAN node as an Intra-Domain NAS Node Selector (IDNNS).

The mapping of P-TMSI (TLLI) and RAI in GERAN/UTRAN to GUTI in E-UTRAN should be performed as follows:

GERAN/UTRAN <MCC>	maps to E-UTRAN <MCC>
GERAN/UTRAN <MNC>	maps to E-UTRAN <MNC>
GERAN/UTRAN <LAC>	maps to E-UTRAN <MME Group ID>
GERAN/UTRAN <RAC>	maps to 8 bits of the M-TMSI

The eight most significant bits of GERAN/UTRAN <NRI> map to the MMEC.

GERAN/UTRAN <P-TMSI or TLLI> excluding the eight most significant bits at the NRI position maps to the remaining bits of the M-TMSI.

The values of <LAC> and <MME group id> should be disjoint, so that they can be differentiated. It is recommended that the most significant bit of the <LAC> be set to zero, and the most significant bit of <MME group id> set to one.

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.