Roamer authentication in visited network
To ensure security and to deny services to an unauthorized visitor, the VPLMN has to validate a roamer as an authorized subscriber before granting permission to roam in its network. The VPLMN may also authenticate roamers periodically on observing further activities.
Figure 6-11 Example message decode for update location (response).
In this case, however, triplets, i.e., RAND, SRES, and Kc are sent between PLMNs over connecting networks.
The VPLMN VLR initiates the MAP send authentication info procedure to retrieve authentication information from the HPLMN HLR. The response from an HPLMN HLR contains the authentication set list parameter. This list contains a set of authentication triplets, i.e., RAND, SRES, and Kc.
The transfer of authentication key triplets between the HPLMN HLR and the VPLMN VLR is shown in Figure 6-12. The sequence shown is according to the MAPv2 protocol specification. For MAPv1, the MAP send parameter (authentication sets) procedure is invoked instead.
A set of one to five authentication triplets is transferred from the HPLMN HLR to the VPLMN VLR for a successful authentication.
If the VLR receives a MAP send authentication info response containing a user error parameter as part of the handling of an authentication procedure, the authentication procedure in the VLR will fail.
The IMSI of the roamer is sent as a parameter within the MAP send authentication info request message from the VPLMN MSC/VLR to the HPLMN HLR. This is used by the HLR to identify roamer.
The MAP send authentication info response from HPLMN HLR to VPLMN MSC/VLR consists of following parameters.
■ Authentication set list
■ User error (if present)
Figure 6-13 shows the HLR provided four sets of triplets to the VLR in response to the send authentication request.
In the event of failure, one of the following error causes can be returned:
■ Unknown subscriber. There is no allocated IMSI or no directory number for the mobile subscriber in the HLR.
■ Unexpected data value. The data type is formally correct, but its value or presence is unexpected in the current context.
■ System failure. The task cannot be performed because of a problem in the other node. The type of node or network resource may be indicated in the network resource parameter.
■ Data missing. An optional parameter that is required by the context is missing.
Provide roaming number
This section describes the roaming procedures initiated by the HPLMN to route terminating calls to its subscribers when roaming in a foreign network.
Figure 6-12 Send authentication procedure.
Figure 6-13 Example message decode – Send Authentication Info
The first step for the HPLMN MSC responsible for routing the call is to get routing information from the local HLR. This is done via the send routing information (SRI) procedure that takes place between the MSC and the HLR. The HLR, on receiving a SRI request, checks the subscriber’s status, and, on determining that the subscriber is in a foreign network, invokes the provide roaming number (PRN) procedure toward the VPLMN VLR to get the temporarily assigned mobile subscriber roaming number (MSRN) to the roamer.
Figure 6-14 shows the send routing info and provide roaming number procedures. The detailed steps are as follows.
1. The GMSC responsible for routing a terminating call invokes an MAP send routing information request toward the HLR with the called party MSISDN as the key parameter.
2. The HLR looks at its database and, on finding that the called subscriber is visiting a foreign network, invokes the MAP provide roaming number procedure toward the VPLMN VLR with the roamer’s IMSI and MSISDN and the E.164 MSC number currently serving the MS.
3. The serving VPLMN VLR checks if the roamer is still in its network and assigns a temporarily number for routing purposes, i.e., MSRN. If the VPLMN VLR is unable to assign a MSRN to the roaming MS, the provide roaming number procedure fails. The VPLMN VLR then returns a response with the appropriate error code. On successful assignment, the VPLMN VLR sends MSRN in response to PRN request.
4. On receiving a successful response from the VPLMN VLR, the HLR sends an acknowledgment to the GMSC with the MSRN and the VMSC (visited MSC) address.
5. The MSC then invokes normal ISUP procedures toward the VPLMN to route the incoming call to the roamer.
Figure 6-15 shows the protocol decodes for the provide roaming number procedure. In this example, the MSRN is successfully delivered to the HLR.
The errors associated with the provide roaming number procedure are as follows.
■ Absent subscriber. This indicates that the location of the roamer is not known (either the roamer is not registered and no location information is available or the provide roaming number procedure has failed because of the IMSI detached flag being set).
■ No roaming number available. A roaming number cannot be allocated because all the available MSRNs in a VMSC are already in use.
■ Facility not supported
Figure 6-14 Provide roaming number procedure.
Figure 6-15 Example message decode for provide roaming number.
■ Unexpected data value. The data type is formally correct but its value or presence is unexpected in the current context.
■ System failure. The task cannot be performed because of a problem in other entity. The type of entity or network resource may be indicated by the network resource parameter.
■ Data missing. An optional parameter required by the context is missing.
Figure 6-16 shows the provide roaming response with an error.
Cancel location
When a roamer moves from one VLR area to another area within the PLMN where it was initially roaming or switches to another PLMN, the HPLMN HLR uses the cancel location procedure to inform the old VLR. On receiving this message, the old VLR deletes the roamer’s data from its database.
The MAP cancel location request carries the roamer’s IMSI (for which this procedure was invoked) as a parameter.
Purge MS
The VPLMN VLR deletes the roamer’s record from its database, if a roamer is inactive for a extended period of time, and sends a MAP purge MS request to the HPLMN HLR. On receiving purge MS message from the VLR, the HLR marks (sets the MS purged flag) the MS so that any request for routing information for a mobile-terminated call or mobile-terminated short message will be treated as if the MS were not reachable.
The network provider sets the period after which this procedure should be invoked. This procedure is also invoked in case roamer information needs to be deleted by an operator using a man-machine command.
The MAP purge MS request message carries the roamer’s IMSI (for which the procedure was invoked) as a parameter.
Restore data
A VPLMN VLR invokes the restore data procedure in the following scenario;
■ On receiving a MAP provide roaming number request from the HPLMN HLR for an IMSI that is not known in the VLR.
■ On receiving a MAP provide roaming number request from the HPLMN HLR for a known IMSI for which the confirmed by HLR flag is set to not confirmed. This flag is set because the data is assumed to be not reliable after the HLR restart, as a result of severe error.
Figure 6-16 Example message decode for provide roaming number (response).
Figure 6-17 Restore data procedure.
As shown in Figure 6-17, on receiving a Restore Data message, the HPLMN HLR invokes the insert subscriber data procedure to synchronise the VLR data for a certain roamer/IMSI.
