3.2. Location Updating procedure

Location Updating is initiated when a mobile station performs the first registration in a visited MTX area. The MTXV sends a Location Updating Message, LUM, to the HLR/MTXH. The LUM contains the MS Identity, the MTXV Identity and the MTXV restrictions.

The HLR/MTXH responds with either Location Updating Accepted Message, LUA, or Location Updating Rejected Message, LUR, see fig. 3.2. The LUR contains the reason for the rejection.

An updating signalling procedure ending with the updating message being accepted, causes the following registers to be updated in MTXV and HLR/MTXH.

The «Optional Information Field Indicator Set» field in the LUA indicates if more information may be transferred to the MTXV.

When receiving LUM, HLR/MTXH checks the MTXV Identity. If transfer of the Secret Authentication Key is allowed to this MTX, this is indicated in the "Additional Information" field in the LUA.

If the MS Directory Number is allowed transferred outside the PLMN, this number is also included in the LUA message.

If MTXV and HLR/MTXH do not both belong to the same country, HLR/MTXH shall always convert a national (significant) MS Directory Number to an international number before transferring it to MTXV

If a LUR message is received, the Location Updating procedure will take place every time the MS make a new contact with the network. The exception is when the reason for rejection is set to "Incorrect security code" which shall be handled as specified in NMT 450/900 DOC 2.

The Nordic NMT system will initially have the same set of categories and supplementary services implemented in all the involved countries. Thus, there is no need for procedures following the Location Updating procedure to handle different sets of categories and/ or supplementary services.

Such services can be:

 

 

Figure 3.2 Location Updating procedure.


 

 

3.2.1 Location updating with «Prepaid Call Unit» service

3.2.1.1 General

If the operator creates the subscriber with prepayment of calls, the subscriber category «Prepaid calls» is set. In addition to the category information the subscriber’s data contains information about the amount of the «Prepaid Call Units» which is paid in advance.

The operator updates the balance of the Call Units in the MTXH every time the subscriber buys more «Call Units».

When the subscriber makes a call the balance of prepayment is checked before the call is accepted. If the balance runs out during the call the call is interrupted.

After each call the HLR/MTXH updates the balance. In a multi MTX network the MTXV has to inform the MTXV/HLR about spent call Units by sending a LUM message after each call.

If the balance in HLR/MTXH is updated the balance in MTXV may also be adjusted by HLR/MTXH sending a CSU message.

 

3.2.1.2 Location updating in MTXV

Normal location updating procedure is performed but the LUA includes information about the balance of «Prepaid Call Units».

 

 

Figure 3.2.1.2: Location updating in MTXV when «Prepaid Call Units» service is implemented

 

3.2.1.3 Updating of «Prepaid Call Units» balance in HLR/MTXH

When MS makes a call, the MTXV checks the available Prepaid call Units from the subscriber’s data and sets up the call accordingly.

After each call MTXV updates the balance of Prepaid call Units to MTXH.

 

Figure 3.2.1.3: Updating of «Prepaid Call Units» balance in HLR/MTXH

 

3.2.1.4 Subscriber buys more Prepaid call Units

When the subscriber buys more call Units the operator updates the balance of the Prepaid call Units in the HLR/MTXH. If the subscriber is visiting in another MTX, the new balance is updated even there.

 

 

 

Figure 3.2.1.4: Subscriber buys more Prepaid call Units

 

 

 

 

3.2.2 Prevention of fraudulent Location Updating procedure.

 

3.2.2.1 General

Even if the NMT system has improved security of the subscriber Identity, fraudulent use of the subscriber’s Identity may make inconveniences to receive incoming calls.

Below are some methods to prevent or minimise the fraudulent roaming attempts described.

 

3.2.2.2 Protection methods

The protection methods of fraudulent roaming for the different kind of MSs may be:

In the following some verification-procedures are generally described. The communication between the NMT nodes is also simplified to show only the relevant MUP messages for the actual verification.

3.2.2.3 Roaming updating

When the MS makes a normal roaming updating call in MTXV the serving node asks for the subscriber data with LUM message to HLR/MTXH. If the HLR/MTXH require additional verification of the MS before setting new location in the HLR/MTXH. The HLR/MTXH sends the subscriber data with «All calls barred» and «New location not verified» to the new MTXV in LUA message and leaves the location information to point out the «old location» as destination for terminating calls.

The MTXV may also require certain security levels for roamers in the «MTXV restrictions field» in LUM message.

 

Figure 3.2.2.3: Fraudulent prevented roaming updating call

 

3.2.2.4 Check whether MS is still in the previous location

In order to prevent fraudulent location updating the HLR/MTXH is checking if the MS is still in the «old location».

The check is made by ordering «test page» in the traffic area where the MS last was updated. If the MS responds to the paging, the HLR/MTXH may decide not to accept the new location updating attempt.

Initially, when HLR/MTXH receives the LUM message from the new MTXV, it responds with an «Outgoing call barred» and «New location not verified» in the LUA message.

HLR/MTXH sends HRE/RNE message to the last MTXV with additional information «Make only paging check of the MS» in the «Call origin field».

If MS responds to the paging, the old MTXV returns HRM/RNM message to the HLR/MTXH. HLR/MTXH leaves the «location information» unchanged and due to the «Outgoing Call Barred Value» the fraudulent MS can not originate calls.

If the MS is busy when MTXV initiates the paging check, MTXV interprets this as the MS is still in the old location.

In order to «clean up» the visitor-register in the «Fraudulent NMT-node» the HLR/MTXH sends a LCM.

In order to prevent disturbance by repeated fraudulent roaming update attempts HLR/MTXH may suppress the LCM and leave the subscriber data in MTXV unchanged. After a certain period (i.e., 24 hours) MTXV may clean the visitor register for subscribers that have not completed the verification.

 

Figure 3.2.2.4a MS is active in the previous location, New location denied

 

If MS does not respond to the paging, the old MTXV sends RNR/HRR to HLR/MTXH.

The HLR/MTXH is cancelling the old location by sending an LCM, sets the new «location» and sends the CSU message to the new MTXV with the subscriber’s actual barring categories and «New location accepted» in the information field for subscription status.

 

Figure 3.2.2.4b: MS is not active in the previous location, new location verified

3.2.2.5 PIN code check before final acceptance of Location Updating

Location updating procedure is carried out as a normal fraudulent prevented roaming updating call but initially, when HLR/MTXH receives the LUM message from the new MTXV, it responds with an «Outgoing Call Barred Value» and a «Verification by Pin-code required» in the «Information field for Subscription Status» in LUA message.

The MTXV then carries out a test of the validity of the MS by requiring PIN code in the first call attempt.

The MS initiates a special supplementary service registration/ cancellation procedure transferring the PIN code from the MTXV to the HLR/MTXH for validation.

If the PIN code is correct HLR/MTXH accepts the new location and sends a CSU with the actual «call barred categories» and «New location accepted» in the Information field for Subscription Status.

 

Figure 3.2.2.5a: PIN code check before final acceptance of Location Updating, successful procedure

If the PIN code is not correct HLR/MTXH does not accepts the new location, sends a SRA message to the MTXV with «Faulty manipulation of service» and denies to set the new location. In order to prevent blocking due to erroneous number-keying by the legal subscriber there may be predefined numbers of faulty manipulations before HLR/MTXH denies the new location.

With repeated unsuccessful location updating attempts there should not be necessary to send repeated LCM messages.

 

 

Figure 3.2.2.5b: PIN code check before final acceptance of

Location Updating, unsuccessful procedure

 

3.2.2.6 SIS verification before final acceptance of Location Updating

Location updating procedure is carried out as a normal fraudulent prevented roaming updating call but initially, when HLR/MTXH receives the LUM message from the new MTXV, it responds with an «Outgoing Call Barred Value» and a «Verification by SIS required» in the «Information field for Subscription Status» in LUA message.

 

 

 

Figure 3.2.2.6: SIS verification before final acceptance

of Location Updating

 

3.2.2.6.1 NMT-450i system

MTXV makes a test call to MS. When the subscriber answers, MTXV makes the SIS check according to the procedure of Authentication during conversation.

If the test call and SIS check succeeds, MTXV completes the location updating by sending LUM to HLR/MTXH with «Location updating verified with SIS» in the MTXV restrictions field.

If the test-call attempt fails, and SIS verification cannot be made, MTXV waits for the first call attempt from MS.

When the call is originated MTXV carries out the SIS verification. If the verification is succeeded MTXV completes the location updating by sending LUM to HLR/MTXH with «SIS-verified Roaming Updating» in the «MTXV restrictions field».

The HLR/MTXH responds with LUA containing actual «Call barring values», «New location accepted» and sets the new location.

 

3.2.2.6.2 NMT 900 system

As there is no «SIS-verification during conversation» in this system the MTXV waits for the first call attempt and makes then the SIS verification.

If the SIS check succeeds, MTXV completes the location updating by sending LUM to HLR/MTXH and follows the same procedure as in the NMT-450i.

 

3.2.2.7 SIS-controlled Location Updating

This function is extending the already implemented SIS Authentication functionality to be used also in the Location Updating procedure. The procedure shall be used for all mobile stations. If the mobile station is not able to fulfil the procedure the procedure shall be performed without SIS-authentication.

The network shall mainly handle the following services:

If the Authentication is unsuccessful the Location Updating shall be denied and the attempt shall be logged the same way as in the ordinary authentication procedures.

Figure 3.2.2.7a SIS-controlled Location Updating, successful procedure

 

 

Figure 3.2.2.7b SIS-controlled Location Updating, unsuccessful procedure