Access (RA)‐RNTI – RA‐RNTI unambiguously identifies which time‐frequency resource was utilized by the UE to transmit the Random Access Preamble. The eNodeB uses the RA‐RNTI in the RAR from the E‐UTRAN to UE. The eNodeB scrambles Physical Downlink Control Channel’s (PDCCH's) CRC with RA‐RNTI for transmission of PDSCH that carries RAR(s).
M‐RNTI – It is used to notify a UE about an MCCH information change.
5.5 Usages of Network Identities
An ongoing end‐to‐end call for a UE/MS involves resource allocations by the different network elements of a communication network. In this regard, each network element assigns its respective network identities, having local or end‐to‐end significance, which is used to keep track of the various resources allocated by them. When an ongoing call is completed, the network elements release the allocated resources as identified by the respective network identities.
At times, the end‐to‐end troubleshooting of an issue may be confusing using the different network identities. The corresponding identities are used during the analysis of the different call processing events, both signaling and user data, to isolate the source of the issue, i.e. network elements. Once a network element is isolated from the probable root cause, the same events may be tracked further on the peer network element using the corresponding identities that are used in that network element.
Note that the network identities are assigned by the different network elements or different protocols layers of a network element. For example, LTE RNTIs are assigned by its Layer 2 MAC layer. Knowing the network identity and its corresponding protocol layer is particularly important during the end‐to‐end troubleshooting of an issue using protocol analysis tools.
5.6 Native and Mapped Network Identities
Network identities assigned to a mobile device can be native or mapped ones.
Native Identity
A network element may construct a native identity from several fundamental identities. A network element may allocate a native identity to another network element for its identification and tracking of various resources allocated to it. An example of native identity in the case of LTE/EPS is the GUTI as shown in Example 5.2; in Figure 5.3. MME assigns a GUTI to a UE and is used during the various EPS mobility management layer procedures. Similarly, in the GPRS system, the SGSN allocates a P‐TMSI to an MS.
Mapped Identity
A mapped identity is derived from a certain portion of a native identity or may assign the whole native identity. One example of mapped identity is the NRI used in a GPRS system that is derived either from a TMSI or P‐TMSI. Similarly, a TLLI, which is used in the GPRS system, is derived from a P‐TMSI, as shown in Example 5.4 and Figure 5.5.
Mapped identity due to intersystem changes
An LTE E‐UTRAN UE may support multiple RATs to provide communication services through legacy networks. Such a UE registers with the legacy CNs also where the respective network identities are allocated to the UE to provide seamless communication service to the user. During the intersystem changes from E‐UTRAN/LTE/EPS to GERAN/UTRAN (UMTS) and vice versa due to its mobility, a UE identity shall be mapped into another identity, as shown in Example 5.5 and Figure 5.6.
Example 5.4 GPRS MS Identity: Mapping an NRI and TLLI into a P‐TMSI
Consider a P‐TMSI of a GPRS mobile subscriber which is of 32 bits in length. The mapping and deriving of an NRI and a TLLI from a P‐TMSI is shown in Figure 5.5.
NRI
An NRI is mapped into the Bits 23rd to 14th of a P‐TMSI.
TLLI
The first two MSBs of a TLLI are set to 1's. The Bits 29th to 0th of a TLLI is mapped into the corresponding bits of a P‐TMSI.
Figure 5.5 GPRS MS identity: mapping of an NRI and TLLI into a P‐TMSI.
Example 5.5 UE Identity Mapping due to the Intersystem Change from GERAN/UTRAN to E‐UTRAN
Due to a UE's intersystem changes from E‐UTRAN/EPS to GERAN/UTRAN (UMTS) and vice versa, the new SGSN or new MME requires to retrieve the UE information from the old SGSN or old MME. Apart from this, identity mapping is also required at the UE end if it wishes to perform a mobility management procedure in the target system.
Consider that an E‐UTRAN capable UE leaves a GERAN/UTRAN coverage area and enters into an E‐UTRAN area and wants to perform an EPS ATTACH mobility management procedure toward the LTE/EPC network. Also, assume that the UE does not have a valid GUTI at present. In this case, the UE maps the existing GERAN/UTRAN domain identities into the E‐UTRAN domain corresponding identities and sends those identities as EPS Mobile Identity in the Attach request message, along with the Old GUTI Type as “Mapped GUTI” to the MME. The GERAN/UTRAN network identities mappings to E‐UTRAN network identities are shown in Table 5.1.
Figure 5.6 shows graphically the mapping of LTE/EPS M‐TMSI from the GERAN/UTRAN P‐TMSI. In the current intersystem change scenario, the visiting and new MME performs the reverse mapping of the identities shown in Table 5.1, and based on these, the new MME is able to contact the old SGSN to retrieve the UE information.
Table 5.1 GERAN‐UTRAN to E‐UTRAN‐EPC: identities mapping.
| GERAN‐UTRAN | E‐UTRAN‐EPC |
|---|---|
| Mobile Country Code (MCC) | Mobile Network Code (MNC) |
| Mobile Network Code (MNC) | Mobile Network Code (MNC) |
| Location Area Code (LAC) | MME Group ID |
| Routing Area Code (RAC) | Bit 23rd to 16th of M‐TMSI |
| 8 Most Significant Bits of NRI | MME Code |
| 29th to 24th bits of P‐TMSI | 29th to 24th bits of M‐TMSI |
| 15th to 0th bits of P‐TMSI |
15th to 0th
|