Mobility management state model in the VLR The VLR functionality in Mobility Management state models has the

following states: The subscriber data of the subscriber is not available in the NonVLR. The location registration attempt triggers a location Registered update towards the HLR. The subscriber data is available in the VLR. The subscriber Registered, can actively use the network, for example, by initiating or Attached receiving calls. The subscriber data is available in the VLR. The registration attempt is denied from the subscriber. The Registered, subscriber cannot actively use the network, for example, by Barred initiating or receiving calls before a successful location registration. Table 45: The states of the VLR functionality in Mobility Management State Models The Mobility Management State Model in the VLR consists of two independent models:

Inter-VLR location registration Mobility Management state model Intra-VLR location registration Mobility Management state model

Inter-VLR location registration state model

Figure 6: Mobility Management State Model in the VLR for inter-VLR location registration

MM-DP1 PLMN-specific-LocUp-DP This DP is intended for roaming subscribers. The MM-DP1 is PLMN-specific, that is, it can be set for all or no subscribers of a foreign network. It can also be armed for home

subscribers, but it is not recommended because of possible overload problems. For home subscribers, the MM-DP4 in the HLR/SSP offers the same functionality as the MM-DP1 for roaming subscribers. Location registration is initiated by the MS. The subscriber is roaming to another VLR area and carries out the inter-VLR location registration. The authentication is carried out, but the location registration to the HLR is not started yet. The SSF starts the transaction towards the SCF. The result of the request is one of the following: 1. The location registration is accepted by the SCF. The location registration is rejected by the SCF. The VLR passes the reject cause to the MS 2. and acts according to the reject cause (?registered, barred/non-registered).

MM-DP2 Inter-VLR-LocUp-DP The MM-DP2 is subscriber-specific. The subscriber data indicates whether the DP is armed or not. The subscriber data is transferred to the VLR, and the HLR accepts the registration. The success of the registration attempt is not yet indicated to the Mobile Station. Optionally, an IMEI checking is carried out. The SSF starts the transaction towards the SCF. The result of the request is one of the following:

1. The location registration is accepted by the SCF. The SCF sends the charging information (FCI) to the SSF and accepts the location 2. registration. The location registration is rejected by the SCF. The VLR passes the reject cause to the MS 3. and acts according to the reject cause (?registered, barred/non-registered). Intra-VLR location registration state model

Figure 7: Mobility Management State Model in the VLR for intra-VLR location registration

MM-DP3 Intra-VLR-LocUp-DP The MM-DP3 is subscriber-specific. That is, the subscriber data indicates whether the DP is armed or not. The intra-VLR location registration is initiated by the MS. If the subscriber was not registered in the VLR (for example, after a VLR cleaning or a reset), the subscriber data is retrieved from the HLR. The authentication is completed. The MS has not yet indicated the success of the registration attempt. As an option, an IMEI checking is carried out. The SSF starts the transaction towards the SCF. The result of the request is one of the following:

1. The location registration is accepted by the SCF. The SCF sends the charging information (FCI) to the SSF and accepts the location 2. registration. The location registration is rejected by the SCF. The VLR passes the reject cause to the MS 3. and acts according to the reject cause (?registered, barred/non-registered). Mobility management state model in the HLR

Figure 8:

Mobility Management state model in the HLR

MM-DP4 HLR-LocUp-DP The MM-DP4 is subscriber specific. The Inter-VLR location registration is received from the new VLR. The IMSI is known by the HLR. The HLR checks whether the subscriber is allowed to roam in the area in question or not. It is also checked that the old VLR address in the database and the new VLR address received in the location registration attempt are not the same, as they could be after a VLR cleaning or a reset. The subscriber data transfer to the new VLR has not been started yet. The SSF starts the transaction towards the SCF. The result of the request is one of the following: The location registration is accepted by the SCF. The HLR stores the new VLR address to 1. the subscriber data. The subscriber data transfer to the new VLR and the cancel location procedure towards the old VLR are started. The location registration is rejected by the SCF. The reject cause received from the SCF is 2. passed to the VLR. The VLR address is removed from the subscriber data.