8 Mobility services

09.023GPPMobile Application Part (MAP) specificationTS

8.1 Location management services

8.1.1 MAP_UPDATE_LOCATION_AREA service

8.1.1.1 Definition

This service is used between MSC and VLR to update location information in the network. It is initiated by an MS when changing the location area or at first registration. The detailed conditions are given in GSM 03.12.

The MAP_UPDATE_LOCATION_AREA service is a confirmed service using the primitives from table 8.1/1.

8.1.1.2 Service primitives

Table 8.1/1: MAP_UPDATE_LOCATION_AREA

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

Target location area Id

M

M(=)

Serving cell Id

M

M(=)

Location update type

M

M(=)

IMSI

C

C(=)

TMSI

C

C(=)

Previous location area Id

C

C(=)

CKSN

C

C(=)

User error

C

C(=)

Provider error

O

8.1.1.3 Parameter definitions and use

Invoke Id

See definition in subclause 7.6.1.

Target location area Id

See definition in subclause 7.6.2.

Serving cell Id

See definition in subclause 7.6.2.

Location update type

See definition in subclause 7.6.9.

IMSI

See definition in subclause 7.6.2. It is up to the MS to provide either IMSI or TMSI, but one shall be present.

TMSI

See definition in subclause 7.6.2. It is up to the MS to provide either IMSI or TMSI, but one shall be present.

Previous location area Id

See definition in subclause 7.6.2. This parameter is provided if the updating is not a first registration.

CKSN

See definition in subclause 7.6.7. The CKSN is given if TMSI is used.

User error

One of the following error causes defined in subclause 7.6.1 is sent by the user in case of location area updating failures, depending on the failure reason:

– unknown subscriber;

This cause is used if the subscriber is not known in the VLR and even a correlated request to the subscriber’s HLR gives a negative result (i.e. the IMSI is not allocated to a subscriber).

– unknown location area;

This cause is used if the target location area identity given is not known in the VLR.

– roaming not allowed;

This cause is used if the MS is not allowed to roam into the target location area indicated in the MAP_UPDATE_LOCATION_AREA Req. The cause will be qualified according to the roaming restriction reason, i.e. one of "National Roaming Not Allowed", "PLMN Not Allowed", "Location Area Not Allowed", or "Operator Determined Barring".

– illegal subscriber;

This error is sent if a correlated authentication procedure has not authenticated the subscriber.

– illegal equipment;

This error is sent if an IMEI check failed, i.e. the IMEI is blacklisted or not white-listed.

– system failure;

– unexpected data value.

Provider error

For definition of provider errors see subclause 7.6.1.

8.1.2 MAP_UPDATE_LOCATION service

8.1.2.1 Definition

This service is used by the VLR to update the location information stored in the HLR.

The MAP_UPDATE_LOCATION service is a confirmed service using the service primitives given in table 8.1/2.

8.1.2.2 Service primitives

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

IMSI

M

M(=)

MSC Address

M

M(=)

VLR number

M

M(=)

LMSI

U

C(=)

Supported CAMEL Phases

C

C(=)

HLR number

C

C(=)

User error

C

C(=)

Provider error

O

Table 8.1/2: MAP_UPDATE_LOCATION

8.1.2.3 Parameter definitions and use

Invoke Id

See definition in subclause 5.6.1.

IMSI

See definition in subclause 5.6.2.

MSC Address

See definition in subclause 5.6.2. The MSC address is used for short message delivery only and for each incoming call set-up attempt the MSRN will be requested from the VLR.

VLR number

See definition in subclause 5.6.2.

LMSI

See definition in subclause 5.6.2. It is an operator option to provide the LMSI from the VLR; it is mandatory for the HLR to support the LMSI handling procedures.

Supported CAMEL Phases

This parameter indicates which phases of CAMEL are supported. Must be present if a CAMEL phase different from phase 1 is supported. Otherwise may be absent.

HLR number

See definition in subclause 5.6.2. The presence of this parameter is mandatory in case of successful HLR updating.

User error

In case of unsuccessful updating, an error cause shall be returned by the HLR. The following error causes defined in subclause 5.6.1 may be used, depending on the nature of the fault:

– unknown subscriber;

– roaming not allowed;

This cause will be sent if the MS is not allowed to roam into the PLMN indicated by the VLR number. The cause is qualified by the roaming restriction reason "PLMN Not Allowed" or "Operator Determined Barring". If no qualification is received (HLR with MAP Version 1), "PLMN Not Allowed" is taken as default.

– system failure;

– unexpected data value.

Provider error

For definition of provider errors see subclause 5.6.1.

8.1.3 MAP_CANCEL_LOCATION service

8.1.3.1 Definition

This service is used between HLR and VLR to delete a subscriber record from the VLR. It may be invoked automatically when an MS moves from one VLR area to another, to remove the subscriber record from the old VLR, or by the HLR operator to enforce a location updating from the VLR to the HLR, e.g. on withdrawal of a subscription.

Also this service is used between HLR and SGSN to delete a subscriber record from the SGSN. It may be invoked automatically when an MS moves from one SGSN area to another, to remove the subscriber record from the old SGSN, or by the HLR operator to enforce a location updating from the SGSN to the HLR.

The MAP_CANCEL_LOCATION service is a confirmed service using the primitives defined in table 8.1/3.

8.1.3.2 Service primitives

Table 8.1/3: MAP_CANCEL_LOCATION

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

IMSI

M

M(=)

LMSI

C

C(=)

Cancellation Type

C

C(=)

User error

C

C(=)

Provider error

O

8.1.3.3 Parameter definitions and use

Invoke Id

See definition in subclause 7.6.1.

IMSI

See definition in subclause 7.6.2.

LMSI

See definition in subclause 7.6.2. The LMSI shall be included if it has been received from VLR. LMSI is not applicable between SGSN and HLR.

Value 0000 0000 can be used to indicate that the LMSI is not in use.

Cancellation Type

See definition in subclause 5.6.3. The presence of this parameter is mandatory when the Cancel Location is sent to the SGSN. If the VLR receives this parameter and do not understand it the VLR shall ignore it.

User error

If the cancellation fails, an error cause is to be returned by the VLR or by the SGSN. The one of the following error causes defined in subclause 5.6.1 shall be used:

– unexpected data value;

– data missing.

Provider error

For definition of provider errors see subclause 7.6.1.

8.1.4 MAP_SEND_IDENTIFICATION service

8.1.4.1 Definition

The MAP_SEND_IDENTIFICATION service is used between a VLR and a previous VLR to retrieve IMSI and authentication sets for a subscriber registering afresh in that VLR.

The MAP_SEND_IDENTIFICATION service is a confirmed service using the service primitives defined in table 8.1/4.

8.1.4.2 Service primitives

Table 8.1/4: MAP_SEND_IDENTIFICATION

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

TMSI

M

M(=)

IMSI

C

C(=)

Authentication set

U

C(=)

User error

C

C(=)

Provider error

O

8.1.4.3 Parameter definitions and use

Invoke Id

See definition in subclause 7.6.1.

TMSI

See definition in subclause 7.6.2.

IMSI

See definition in subclause 7.6.2. The IMSI is to be returned if the service succeeds.

Authentication set

See definition in subclause 7.6.7. If the service succeeds a list of up to five authentication sets is returned, if there are any available.

User error

This parameter is mandatory if the service fails. The following error cause defined in subclause 7.6.1 may be used, depending on the nature of the fault:

– unidentified subscriber.

Provider error

For definition of provider errors see subclause 7.6.1.

8.1.5 MAP_DETACH_IMSI service

8.1.5.1 Definition

The MAP_DETACH_IMSI service is used by the MSC to indicate to the VLR that an MS is no longer reachable. The network needs this information e.g. to reject an incoming call without initiating paging on the radio path.

The MAP_DETACH_IMSI service is a non-confirmed service using the service primitives defined in table 8.1/5.

8.1.5.2 Service primitives

Table 8.1/5: MAP_DETACH_IMSI

Parameter name

Request

Indication

Invoke Id

M

M(=)

Serving cell id

M

M(=)

IMSI

C

C(=)

TMSI

C

C(=)

8.1.5.3 Parameter definitions and use

Invoke Id

See definition in subclause 7.6.1.

Serving cell id

See definition in subclause 7.6.2.

IMSI

See definition in subclause 7.6.2. It is up to the MS to provide either IMSI or TMSI as subscriber identity, but one shall be present.

TMSI

See definition in subclause 7.6.2. It is up to the MS to provide either IMSI or TMSI as subscriber identity, but one shall be present.

8.1.6 MAP_PURGE_MS service

8.1.6.1 Definition

This service is used between the VLR and the HLR to cause the HLR to mark its data for an MS so that any request for routing information for a mobile terminated call or a mobile terminated short message will be treated as if the MS is not reachable. It is invoked when the subscriber record for the MS is to be deleted in the VLR, either by MMI interaction or automatically, e.g. because the MS has been inactive for several days.

Also this service is used between the SGSN and the HLR to cause the HLR to mark its data for an MS so that any request for routing information for a mobile terminated short message or a network requested PDP-context activation will be treated as if the MS is not reachable. It is invoked when the subscriber record for the MS is to be deleted in the SGSN, either by MMI interaction or automatically, e.g. because the MS has been inactive for several days.

The MAP_PURGE_MS service is a confirmed service using the primitives defined in table 8.1/6.

8.1.6.2 Service primitives

Table 8.1/6: MAP_PURGE_MS

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

IMSI

M

M(=)

VLR number

C

C(=)

Freeze TMSI

C

C(=)

Freeze P-TMSI

C

C(=)

SGSN number

C

C(=)

User error

C

C(=)

Provider error

O

8.1.6.3 Parameter definitions and use

Invoke ID

See definition in subclause 7.6.1.

IMSI

See definition in subclause 7.6.2.

VLR number

Shall be present if the sender is VLR. See definition in subclause 7.6.2.

SGSN number

Shall be present if the sender is SGSN. See definition in subclause 7.6.2

Freeze TMSI

This parameter is sent to the VLR to indicate that the TMSI has to be frozen. It shall be present if the received VLR number matches the stored VLR number.

Freeze P-TMSI

This parameter is sent to the SGSN to indicate that the P-TMSI has to be frozen. It shall be present if the received SGSN number matches the stored SGSN number.

User error

This parameter is sent by the responder when an error is detected and if present, takes one of the following values:

– Data Missing;

– Unexpected Data Value;

– UnknownSubscriber.

Provider error

See definition of provider errors in subclause 7.6.1.

8.1.7 MAP_UPDATE_GPRS_LOCATION service

8.1.7.1 Definition

This service is used by the SGSN to update the location information stored in the HLR.

The MAP_UPDATE_GPRS_LOCATION service is a confirmed service using the service primitives given in table 8.1/7.

8.1.7.2 Service primitives

Table 8.1/7: MAP_UPDATE_GPRS_LOCATION

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

IMSI

M

M(=)

SGSN number

M

M(=)

SGSN address

M

M(=)

HLR number

C

C(=)

User error

C

C(=)

Provider error

O

8.1.7.3 Parameter definitions and use

Invoke Id

See definition in subclause 7.6.1.

IMSI

See definition in subclause 7.6.2.

SGSN number

See definition in subclause 7.6.2.

SGSN address

See definition in subclause 7.6.2.

HLR number

See definition in subclause 7.6.2. The presence of this parameter is mandatory in case of successful HLR updating.

User error

In case of unsuccessful updating, an error cause shall be returned by the HLR. The following error causes defined in subclause 7.6.1 may be used, depending on the nature of the fault:

– unknown subscriber;

– roaming not allowed;

This cause will be sent if the MS is not allowed to roam into the PLMN indicated by the SGSN number. The cause is qualified by the roaming restriction reason "PLMN Not Allowed" or "Operator Determined Barring".

– system failure;

– unexpected data value.

The diagnostic in the Unknown Subscriber may indicate “Imsi Unknown” or “Gprs Subscription Unknown”.

Provider error

For definition of provider errors see subclause 7.6.1.

8.2 Paging and search

8.2.1 MAP_PAGE service

8.2.1.1 Definition

This service is used between VLR and MSC to initiate paging of an MS for mobile terminated call set-up, mobile terminated short message or unstructured SS notification.

The MAP_PAGE service is a confirmed service using the primitives from table 8.2/1.

8.2.1.2 Service primitives

Table 8.2/1: MAP_PAGE

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

IMSI

M

M(=)

Stored location area Id

M

M(=)

TMSI

U

C(=)

User error

C

C(=)

Provider error

O

8.2.1.3 Parameter definitions and use

Invoke Id

See definition in subclause 7.6.1.

IMSI

See definition in subclause 7.6.2. The IMSI is used to define the paging subgroup. If the TMSI is not supplied, paging on the radio path uses the IMSI as an identifier.

Stored location area Id

See definition in subclause 7.6.2.

TMSI

See definition in subclause 7.6.2. The TMSI is included if paging on the radio channel is to use the TMSI as an identifier.

User error

The following error causes defined in subclause 7.6.1 may be sent by the user in case of a paging error, depending on the failure reason:

– absent subscriber;

– unknown location area;

– busy subscriber;

– system failure;

This corresponds to the case where there is no call associated with the MAP_PAGE service, i.e. if the call has been released but the dialogue to the VLR has not been aborted.

– unexpected data value.

Provider error

See definition in subclause 7.6.1.

8.2.2 MAP_SEARCH_FOR_MS service

8.2.2.1 Definition

This service is used between VLR and MSC to initiate paging of an MS in all location areas of that VLR. It is used if the VLR does not hold location area information confirmed by radio contact.

The MAP_SEARCH_FOR_MS service is a confirmed service using the primitives from table 8.2/2.

8.2.2.2 Service primitives

Table 8.2/2: MAP_SEARCH_FOR_MS

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

IMSI

M

M(=)

Current location area Id

C

C(=)

User error

C

C(=)

Provider error

O

8.2.2.3 Parameter definitions and use

Invoke Id

See definition in subclause 7.6.1.

IMSI

See definition in subclause 7.6.2. The IMSI is used to identify the subscriber when paging on the radio path.

Current location area Id

See definition in subclause 7.6.2. In case of successful outcome of the service, i.e. if the MS responds to paging, the Location Area Id of the area in which the MS responded is given in the response.

User error

The following error causes defined in subclause 7.6.1 shall be sent by the user if the search procedure fails, depending on the failure reason:

– absent subscriber;

This error cause is returned by the MSC if the MS does not respond to the paging request.

– system failure;

This corresponds to the case where there is no call associated with the MAP_SEARCH_FOR_MS service, i.e. if the call has been released but the dialogue to the VLR has not been aborted.

– busy subscriber;

– unexpected data value.

Provider error

See definition in subclause 7.6.1.

8.3 Access management services

8.3.1 MAP_PROCESS_ACCESS_REQUEST service

8.3.1.1 Definition

This service is used between MSC and VLR to initiate processing of an MS access to the network, e.g. in case of mobile originated call set-up or after being paged by the network.

The MAP_PROCESS_ACCESS_REQUEST service is a confirmed service using the primitives from table 8.3/1.

8.3.1.2 Service primitives

Table 8.3/1: MAP_PROCESS_ACCESS_REQUEST

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

CM service type

M

M(=)

Access connection status

M

M(=)

Current Location Area Id

M

M(=)

Serving cell id

M

M(=)

TMSI

C

C(=)

Cksn

C

C(=)

IMSI

C

C(=)

C

C(=)

IMEI

C

C(=)

C

C(=)

MSISDN

U

C(=)

User error

C

C(=)

Provider error

O

8.3.1.3 Parameter definitions and use

Invoke Id

See definition in subclause 7.6.1.

CM service type

See definition in subclause 7.6.9.

Access connection status

See definition in subclause 7.6.9.

Current Location Area Id

See definition in subclause 7.6.2. This parameter is used to update the VLR in case of previous VLR failure.

Serving cell id

See definition in subclause 7.6.2.

TMSI

See definition in subclause 7.6.2. Either TMSI or IMSI as received from the MS are included in the Request/Indication, but one shall be present. In case of CM Service Type "Emergency Call Establishment", the IMEI may replace IMSI/TMSI.

Cksn

See definition in subclause 7.6.7. In case of access with TMSI, the Cksn shall be present.

IMSI

See definition in subclause 7.6.2. Either TMSI or IMSI as received from the MS are included in the Request/Indication, but one shall be present. In case of CM Service Type "Emergency Call Establishment", the IMEI may replace IMSI/TMSI.

In the Response/Confirmation, the IMSI is to be sent in case of successful outcome of the service. In case of CM Service Type "Emergency Call Establishment", IMEI may replace IMSI.

IMEI

See definition in subclause 7.6.2. The IMEI may replace IMSI/TMSI in the Request/Indication and IMSI in the Response/Confirmation only in case the CM Service Type indicates "Emergency Call Establishment".

MSISDN

See definition in subclause 7.6.2. The MSISDN is included in case of successful outcome of the service as an operator option, e.g. if it is needed at the MSC for charging purposes in case of call forwarding.

User error

One of the following error causes defined in subclause 7.6.1 shall be sent by the user if the access request fails, depending on the failure reason:

– unidentified subscriber;

– illegal subscriber;

This error is sent if a correlated authentication procedure has not authenticated the subscriber.

– illegal equipment;

This error is sent if an IMEI check failed, i.e. the IMEI is blacklisted or not white-listed.

– roaming not allowed;

This cause is used after VLR restart if the subscriber has no subscription for the current location area, e.g. due to regional subscription. The cause will be qualified by "location area not allowed" or "national roaming not allowed", respectively.

– unknown location area;

– system failure;

– unexpected data value.

Provider error

For definition of provider errors see subclause 7.6.1.

8.4 Handover services

8.4.1 MAP_PREPARE_HANDOVER service

8.4.1.1 Definition

This service is used between MSC-A and MSC-B (E-interface) when a call is to be handed over from MSC‑A to MSC‑B.

The MAP_PREPARE_HANDOVER service is a confirmed service using the primitives from table 8.4/1.

8.4.1.2 Service primitives

Table 8.4/1: MAP_PREPARE_HANDOVER

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

Target Cell Id

C

C(=)

HO-NumberNotRequired

C

C(=)

BSS-APDU

C

C(=)

C

C(=)

Handover Number

C

C(=)

User error

C

C(=)

Provider error

O

8.4.1.3 Parameter use

Invoke Id

For definition of this parameter see subclause 7.6.1.

Target Cell Id

For definition of this parameter see subclause 7.6.2. This parameter is only included if the service is not in an ongoing transaction.

HO-Number Not Required

For definition of this parameter see subclause 7.6.6.

BSS-APDU

For definition of this parameter see subclause 7.6.9.

Handover Number

For definition of this parameter see subclause 7.6.2. This parameter shall be returned, unless the parameter HO-NumberNotRequired is sent.

User error

For definition of this parameter see subclause 7.6.1. The following errors defined in subclause 7.6.1 may be used, depending on the nature of the fault:

– No handover number available;

– System failure;

– Unexpected data value;

– DataMissing.

Provider error

See definition of provider errors in subclause 7.6.1.

8.4.2 MAP_SEND_END_SIGNAL service

8.4.2.1 Definition

This service is used between MSC-B and MSC-A (E-interface) indicating that the radio path has been established by MSC-B to the MS. MSC-A retains then the main control of the call until it clears.

The response is used by MSC-A to inform MSC-B that all resources for the call can be released in MSC-B, either because the call has been released in MSC-A or because the call has been successfully handed over from MSC-B to another MSC.

The MAP_SEND_END_SIGNAL service is a confirmed service using the primitives from table 8.4/2.

8.4.2.2 Service primitives

Table 8.4/2: MAP_SEND_END_SIGNAL

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

BSS-APDU

M

M(=)

Provider error

O

8.4.2.3 Parameter use

Invoke Id

For definition of this parameter see subclause 7.6.1.

BSS-APDU

For definition of this parameter see subclause 7.6.9.

Provider error

For definition of this parameter see subclause 7.6.1.

8.4.3 MAP_PROCESS_ACCESS_SIGNALLING service

8.4.3.1 Definition

This service is used between MSC-B and MSC-A (E-interface) to pass information received on the A‑interface in MSC‑B to MSC‑A.

The MAP_PROCESS_ACCESS_SIGNALLING service is a non-confirmed service using the primitives from table 8.4/3.

8.4.3.2 Service primitives

Table 8.4/3: MAP_PROCESS_ACCESS_SIGNALLING

Parameter name

Request

Indication

Invoke Id

M

M(=)

BSS-APDU

M

M(=)

8.4.3.3 Parameter use

Invoke Id

For definition of this parameter see subclause 7.6.1.

BSS-APDU

For definition of this parameter see subclause 7.6.9.

8.4.4 MAP_FORWARD_ACCESS_SIGNALLING service

8.4.4.1 Definition

This service is used between MSC-A and MSC-B (E-interface) to pass information to be forwarded to the A-interface of MSC-B.

The MAP_FORWARD_ACCESS_SIGNALLING service is a non-confirmed service using the primitives from table 8.4/4.

8.4.4.2 Service primitives

Table 8.4/4: MAP_FORWARD_ACCESS_SIGNALLING

Parameter name

Request

Indication

Invoke Id

M

M(=)

BSS-APDU

M

M(=)

8.4.4.3 Parameter use

For the definition and use of all parameters and errors, see subclause 7.6.1

Invoke Id

For definition of this parameter see subclause 7.6.1.

BSS-APDU

For definition of this parameter see subclause 7.6.9.

8.4.5 MAP_PREPARE_SUBSEQUENT_HANDOVER service

8.4.5.1 Definition

This service is used between MSC-B and MSC-A (E-interface) to inform MSC-A that it has been decided that a handover to either MSC-A or a third MSC (MSC-B’) is required.

The MAP_PREPARE_SUBSEQUENT_HANDOVER service is a confirmed service using the primitives from table 8.4/5.

8.4.5.2 Service primitives

Table 8.4/5: MAP_PREPARE_SUBSEQUENT_HANDOVER

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

Target Cell Id

M

M(=)

Target MSC Number

M

M(=)

BSS-APDU

M

M(=)

C

C(=)

User error

C

C(=)

Provider error

O

8.4.5.3 Parameter use

Invoke Id

For definition of this parameter see subclause 7.6.1.

Target Cell Id

For definition of this parameter see subclause 7.6.2.

Target MSC Number

For definition of this parameter see subclause 7.6.2.

BSS-APDU

For definition of this parameter see subclause 7.6.9.

User error

For definition of this parameter see subclause 7.6.1. The following error causes defined in subclause 7.6.1 may be used, depending on the nature of the fault:

– Unknown MSC;

– Subsequent handover failure;

– Unexpected data value;

– Data Missing.

Provider error

For definition of this parameter see subclause 7.6.1.

8.4.6 MAP_ALLOCATE_HANDOVER_NUMBER service

8.4.6.1 Definition

This service is used between MSC and VLR (B-interface) to request a handover number.

The MAP_ALLOCATE_HANDOVER_NUMBER service is a confirmed service using the primitives from table 8.4/6.

8.4.6.2 Service primitives

Table 8.4/6: MAP_ALLOCATE_HANDOVER_NUMBER

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

User error

C

C(=)

Provider error

O

8.4.6.3 Parameter use

Invoke Id

For definition of this parameter see subclause 7.6.1.

User error

For definition of this parameter see subclause 7.6.1. The following errors defined in subclause 7.6.1 may be used, depending on the nature of the fault:

– No handover number available.

Provider error

For definition of this parameter see subclause 7.6.1.

8.4.7 MAP_SEND_HANDOVER_REPORT service

8.4.7.1 Definition

This service is used between VLR and MSC-B (B-interface) to transfer the handover number to be forwarded to and used by MSC-A.

The MAP_SEND_HANDOVER_REPORT service is a confirmed service using the primitives from table 8.4/7.

8.4.7.2 Service primitives

Table 8.4/7: MAP_SEND_HANDOVER_REPORT

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

Handover Number

M

M(=)

Linked Id

M

M(=)

Provider error

O

8.4.7.3 Parameter use

Invoke Id

For definition of this parameter see subclause 7.6.1.

Handover Number

For definition of this parameter see subclause 7.6.2.

Linked Id

For definition of this parameter see subclause 7.6.1. This service is linked with MAP_ALLOCATE_HANDOVER_NUMBER.

Provider error

For definition of this parameter see subclause 7.6.1.

8.5 Authentication management services

8.5.1 MAP_AUTHENTICATE service

8.5.1.1 Definition

This service is used between the VLR and the MSC when the VLR receives a MAP service indication from the MSC concerning a location registration, call set-up, operation on a supplementary service or a request from the MSC to initiate authentication.

The service is a confirmed service and consists of four service primitives.

8.5.1.2 Service primitives

The service primitives are shown in table 8.5/1

Table 8.5/1: MAP_AUTHENTICATE parameters

Parameter name

Request

Indication

Response

Confirm

Invoke id

M

M(=)

M(=)

M(=)

RAND

M

M(=)

CKSN

M

M(=)

SRES

M

M(=)

Provider error

O

8.5.1.3 Parameter use

Invoke id

See subclause 7.6.1 for the use of this parameter.

RAND

See subclause 7.6.7 for the use of this parameter.

CKSN

See subclause 7.6.7 for the use of this parameter.

SRES

See subclause 7.6.7 for the use of this parameter.

Provider error

See subclause 7.6.1 for the use of this parameter.

8.5.2 MAP_SEND_AUTHENTICATION_INFO service

8.5.2.1 Definition

This service is used between the VLR and the HLR for the VLR to retrieve authentication information from the HLR. The VLR requests some sets of RAND/SRES/Kc vectors.

Also this service is used between the SGSN and the HLR for the SGSN to retrieve authentication information from the HLR. The SGSN requests some sets of RAND/SRES/Kc vectors.

If the HLR cannot provide the VLR or the SGSN with triplets, an empty response is returned. The VLR or the SGSN may then re-use old authentication triplets, except where this is forbidden under the conditions specified in GSM 03.20 [24].

If the VLR or SGSN 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 or SGSN shall fail.

Security related network functions are further described in GSM 03.20.

The service is a confirmed service and consists of four service primitives.

8.5.2.2 Service primitives

The service primitives are shown in table 8.5/2.

Table 8.5/2: MAP_SEND_AUTHENTICATION_PARAMETERS parameters

Parameter name

Request

Indication

Response

Confirm

Invoke id

M

M(=)

M(=)

M(=)

IMSI

M

M(=)

AuthenticationSetList

C

C(=)

User error

C

C(=)

Provider error

O

8.5.2.3 Parameter use

Invoke id

See subclause 7.6.1 for the use of this parameter.

IMSI

See subclause 7.6.2 for the use of this parameter.

AuthenticationSetList

A set of one to five authentication vectors are transferred from the HLR to the VLR or from the HLR to the SGSN, if the outcome of the service was successful.

User error

One of the following error causes defined in subclause 7.6.1 shall be sent by the user in case of unsuccessful outcome of the service, depending on the respective failure reason:

– unknown subscriber;

– unexpected data value;

– system failure;

– data missing.

Provider error

See subclause 7.6.1 for the use of this parameter.

8.6 Security management services

8.6.1 MAP_SET_CIPHERING_MODE service

8.6.1.1 Definitions

This service is used between the VLR and the MSC to set the ciphering mode and to start ciphering if applicable. It is called when another service requires that information is to be sent on the radio path in encrypted form.

The service is a non-confirmed service and consists of two service primitives.

8.6.1.2 Service primitives

The service primitives are shown in table 8.6/1

Table 8.6/1: MAP_SET_CIPHERING_MODE parameters

Parameter name

Request

Indication

Invoke id

M

M(=)

Ciphering mode

M

M(=)

Kc

C

C(=)

8.6.1.3 Parameter use

Invoke id

See subclause 7.6.1 for the use of this parameter.

Ciphering mode

See subclause 7.6.7 for the use of this parameter.

Kc

The Kc parameter should be included when the ciphering mode parameter indicates that ciphering must be performed.

8.7 International mobile equipment identities management services

8.7.1 MAP_CHECK_IMEI service

8.7.1.1 Definition

This service is used between the VLR and the MSC and between the MSC and the EIR and between the SGSN and EIR to request check of IMEI. If the IMEI is not available in the MSC or in the SGSN, it is requested from the MS and transferred to the EIR in the service request.

The service is a confirmed service and consists of four service primitives.

8.7.1.2 Service primitives

The service primitives are shown in table 8.7/1.

Table 8.7/1: MAP_CHECK_IMEI parameters

Parameter name

Request

Indication

Response

Confirm

Invoke id

M

M(=)

M(=)

M(=)

IMEI

C

C(=)

C

C(=)

Equipment status

C

C(=)

User error

C

C(=)

Provider error

O

8.7.1.3 Parameter use

Invoke id

See subclause 7.6.1 for the use of this parameter.

IMEI

See subclause 7.6.2 for the use of this parameter. The parameter shall not be included in the service request between the VLR and the MSC, but is mandatory in the service request from the MSC to the EIR and from the SGSN to the EIR. It is not included in the service response from the EIR to the MSC or to the SGSN, but is mandatory in the service response from the MSC to the VLR on successful outcome.

Equipment status

See subclause 7.6.4 for the use of this parameter. This parameter is sent by the responder in case of successful outcome of the service.

User error

One of the following error causes defined in subclause 7.6.1 shall be sent by the user in case of unsuccessful outcome of the service, depending on the respective failure reason:

– unknown equipment;

This error is returned by the responder when the IMEI is not known in the EIR.

– system failure;

– unexpected data value.

Provider error

See subclause 7.6.1 for the use of this parameter.

8.7.2 MAP_OBTAIN_IMEI service

8.7.2.1 Definition

This service is used between the VLR and the MSC to request the IMEI. If the IMEI is not available in the MSC, it is requested from the MS.

The service is a confirmed service and consists of four service primitives.

8.7.2.2 Service primitives

The service primitives are shown in table 8.7/2.

Table 8.7/2: MAP_OBTAIN_IMEI parameters

Parameter name

Request

Indication

Response

Confirm

Invoke id

M

M(=)

M(=)

M(=)

IMEI

C

C(=)

User error

C

C(=)

Provider error

O

8.7.2.3 Parameter use

Invoke id

See subclause 7.6.1 for the use of this parameter.

IMEI

See subclause 7.6.2 for the use of this parameter. The parameter IS included in the service response from the MSC to the VLR on successful outcome of the service.

User error

If the service fails, the VLR sends the user error System Failure (see subclause 7.6.1) to the MSC.

Provider error

See subclause 7.6.1 for the use of this parameter.

8.8 Subscriber management services

8.8.1 MAP-INSERT-SUBSCRIBER-DATA service

8.8.1.1 Definition

This service is used by an HLR to update a VLR with certain subscriber data in the following occasions:

– the operator has changed the subscription of one or more supplementary services, basic services or data of a subscriber. Note that in case of withdrawal of a Basic or Supplementary service this primitive shall not be used;

– the operator has applied, changed or removed Operator Determined Barring;

– the subscriber has changed data concerning one or more supplementary services by using a subscriber procedure;

– the HLR provides the VLR with subscriber parameters at location updating of a subscriber or at restoration. In this case, this service is used to indicate explicitly that a supplementary service is not provisioned, if the supplementary service specification requires it. The only supplementary services which have this requirement are the CLIR and COLR services. Network access mode is provided only in restoration.

Also this service is used by an HLR to update a SGSN with certain subscriber data in the following occasions:

– if the GPRS subscription has changed;

– if the network access mode is changed;

– the operator has applied, changed or removed Operator Determined Barring;

– the HLR provides the SGSN with subscriber parameters at GPRS location updating of a subscriber.

It is a confirmed service and consists of the primitives shown in table 6.8/1.

8.8.1.2 Service primitives

Table 8.8/1: MAP-INSERT-SUBSCRIBER-DATA

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

IMSI

C

C(=)

MSISDN

C

C(=)

Category

C

C(=)

Subscriber Status

C

C(=)

Bearer service List

C

C(=)

C

C(=)

Teleservice List

C

C(=)

C

C(=)

Forwarding information List

C

C(=)

Call barring information List

C

C(=)

CUG information List

C

C(=)

SS-Data List

C

C(=)

eMLPP Subscription Data

C

C(=)

Operator Determined Barring General data

C

C(=)

C

C(=)

Operator Determined Barring HPLMN data

C

C(=)

Roaming Restriction Due To Unsupported Feature

C

C(=)

Regional Subscription Data

C

C(=)

VLR CAMEL Subscription Info

C

C(=)

Voice Broadcast Data

C

C(=)

Voice Group Call Data

C

C(=)

Network access mode

C

C(=)

GPRS Subscription Data

C

C(=)

Roaming Restricted In SGSN Due To Unsupported Feature

C

C(=)

North American Equal Access preferred Carrier Id

U

C(=)

SS-Code List

C

C(=)

Regional Subscription Response

C

C(=)

Supported CAMEL Phases

C

C (=)

User error

U

C(=)

Provider error

O

8.8.1.3 Parameter use

Network access mode

This parameter defines if the subscriber has access to MSC/VLR and/or to SGSN. This parameter is used by SGSN and MSC/VLR. In VLR, the parameter is used only as part of Restore Data Procedure and the parameter is not stored in the VLR. This parameter shall always be sent to the SGSN as part of the GPRS subscriber data at GPRS location updating. It shall be sent to the SGSN if it is changed as a result of administrative action.

All parameters are described in subclause 7.6. The following clarifications are applicable:

IMSI

It is only included if the service is not used in an ongoing transaction (e.g. location updating). This parameter is used by the VLR and the SGSN.

MSISDN

It is included either at location updating or when it is changed. The MSISDN sent shall be the basic MSISDN. This parameter is used by the VLR and the SGSN.

Category

It is included either at location updating or when it is changed. This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it.

Subscriber Status

It is included either at location updating or when it is changed.

To apply, remove or update Operator Determined Barring Categories the Subscriber Status is set to Operator Determined Barring. In this case ODB General Data shall also be present. If the Operator Determined Barring applies and the subscriber is registered in the HPLMN and HPLMN specific Operator Determined Barring applies then ODB HPLMN Specific Data shall also be present.

To remove all Operator Determined Barring Categories the Subscriber Status shall be set to "Service Granted". This parameter is used by the VLR and the SGSN.

Bearer service List

A list of Extensible Bearer service parameters (Extensible Bearer service is defined in subclause 7.6). An Extensible Bearer service parameter must be the code for an individual Bearer service, except in the cases described below.

The codes for the Bearer service groups "allAlternateSpeech-DataCDA" and "allAlternateSpeech-DataCDS" shall, if applicable, be sent from the HLR to the VLR as a pair. The codes for the Bearer service groups "allSpeechFollowedByDataCDA" and "allSpeechFollowedByDataCDS" shall, if applicable, be sent from the HLR to the VLR as a pair.

If it is included in the Request/Indication, it includes either all Extensible Bearer services subscribed (at location updating or at restoration) or only the ones added (at subscriber data modification).

If the VLR receives an Indication containing any Extensible Bearer service parameters which it does not support/allocate it returns them in the response to the HLR and discards the unsupported Extensible Bearer services (no error is sent back), except in the cases described below.

If the VLR receives the codes for the Bearer service groups "allSpeechFollowedByDataCDA" and "allSpeechFollowedByDataCDS" and supports one or more of the circuit-switched synchronous or asynchronous data rates specified for simple data bearer services, it shall accept the bearer service codes, and not return them in the response to the HLR. If the VLR does not support any of the circuit-switched synchronous or asynchronous data rates specified for simple data bearer services, and receives the pair of codes for "allAlternateSpeech-DataCDA" and "allAlternateSpeech-DataCDS" or the pair of codes for "allSpeechFollowedByDataCDA" and "allSpeechFollowedByDataCDS", it shall reject the pair of codes by returning them in the response to the HLR. This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it.

Teleservice List

A list of Extensible Teleservice parameters (Extensible Teleservice is defined in subclause 7.6). An Extensible Teleservice parameter must be the code for an individual Teleservice.

If it is included in the Request/Indication, it contains either all Extensible Teleservices subscribed (at location updating or at restoration) or the ones added (at subscriber data modification). Only the Extensible Teleservices that are relevant to the node at which the message is received should be included in the Teleservice List.

If the VLR or the SGSN receives an Indication containing any Extensible Teleservice parameters which it does not support/allocate it returns them in the response to the HLR and discards the unsupported Extensible Teleservices (no error is sent back). This parameter is used by the VLR and the SGSN.

Forwarding information List

A list of Extensible Forwarding information parameters (Extensible Forwarding information is defined in subclause 7.6). It includes Call Forwarding services either at location updating or at restoration or when they are changed. Each Extensible Forwarding information parameter shall be treated independently of all other parameters in the primitive.

The Extensible Forwarding information shall include the SS-Code for an individual call forwarding supplementary service. The Extensible Forwarding information shall contain one or more Extensible Forwarding Features (Extensible Forwarding Feature is defined in subclause 7.6).

The Extensible Forwarding Feature may include an Extensible Basic Service Group. This shall be interpreted according to the rules in subclause 8.8.1.4.

The Extensible Forwarding Feature shall contain an Extensible SS-Status parameter.

If the Extensible SS-Status indicates that call forwarding is registered then (except for call forwarding unconditional) the Extensible Forwarding Feature shall contain a forwarded-to number and, if available, the forwarded-to subaddress. In other states the forwarded-to number and, if applicable, the forwarded-to subaddress shall not be included. For call forwarding unconditional the forwarded-to number and, if applicable, the forwarded-to subaddress shall not be included. If the VLR does not receive a forwarded-to subaddress then it shall assume that a forwarded-to subaddress has not been registered.

The Extensible Forwarding Feature shall contain the extensible forwarding options (except for call forwarding unconditional where the extensible forwarding options shall not be included). Bits 3 and 4 of the extensible forwarding options shall be ignored by the VLR, and may be set to any value by the HLR.

For call forwarding on no reply: If the extensible SS-Status indicates that call forwarding is registered then the Extensible Forwarding Feature shall contain an extensible no reply condition timer. In other states the no reply condition timer shall not be included.

For call forwarding services other than call forwarding on no reply: The Extensible Forwarding Feature shall not contain a no reply condition timer.

If the VLR receives an Indication containing any Call Forwarding service codes which it does not support/allocate it returns them to the HLR in the parameter SS-Code List and discards the unsupported Call Forwarding service codes (no error is sent back). This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it.

Call barring information List

A list of Extensible Call barring information parameters (Extensible Call barring information is defined in subclause 7.6). It includes Call Barring services either at location updating or at restoration or when they are changed. Each Extensible Call barring information parameter shall be treated independently of all other parameters in the primitive.

The Extensible Call barring information shall include the SS-Code for an individual call barring supplementary service. The Extensible Call barring information shall contain one or more Extensible Call Barring Features (Extensible Call Barring Feature is defined in subclause 7.6).

The Extensible Call Barring Feature may include an Extensible Basic Service Group. This shall be interpreted according to the rules in subclause 8.8.1.4.

The Extensible Call Barring Feature shall contain an extensible SS-Status parameter.

If the VLR receives an Indication containing any Extensible Call Barring service codes which it does not support/allocate it returns them to the HLR in the parameter SS-Code List and discards the unsupported Extensible Call Barring service codes (no error is sent back). This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it.

CUG information List

A list of CUG information list parameters (CUG information is defined in subclause 7.6). It includes CUG information either at location updating or at restoration or when it is changed.

At location updating, restoration or when there is a change in CUG data, the HLR shall include the complete CUG-SubscriptionList and, if there are options per basic group, it shall also include the complete CUG-FeatureList. If there are not options per extensible basic service group the CUG-FeatureList shall not be included.

In any dialogue, the first insertSubscriberData message which contains CUG information shall include a non-empty CUG-SubscriptionList.

When the VLR receives CUG data it shall replace the stored CUG data with the received data set.

If CUG-FeatureList is omitted in the Insert Subscriber Data operation VLR shall interpret that no options per extensible basic service group exist, and then it shall apply the default values i.e. no outgoing access, no incoming access, no preferential CUG exists.

If CUG-Feature is received without preferential CUG, the VLR shall interpret that no preferential CUG applies.

If the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value.

Note that data consistency between CUG subscription data and CUG feature data is the responsibility of the HLR.

If the VLR does not support the CUG service it returns its code to the HLR in the parameter SS-Code List and discards the received information (no error is sent back). This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it.

SS-Data List

A list of Extensible SS-Data parameters (Extensible SS-Data is defined in subclause 7.6). It is sent for any other supplementary service than Call Forwarding, Call Barring, CUG and eMLPP either at location updating or at restoration or when they are changed. Each SS-Data parameter shall be treated independently of all other parameters in the primitive.

The Extensible SS-Data shall include the SS-Code for an individual supplementary service.

The Extensible SS-Data shall contain an Extensible SS-Status parameter and any subscription options that are applicable to the service defined by the SS-Code.

The SS-Data may include a Basic Service Group List. This shall be interpreted according to the rules in subclause 8.8.1.4.

If the VLR receives an Indication containing any supplementary service codes which it does not support/allocate it returns them to the HLR in the parameter SS-Code List and therefore discards the unsupported service codes received (no error is sent back). This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it.

Operator Determined Barring General data

If it is included in a Request/Indication, it includes all the Operator Determined Barring categories that may be applied to a subscriber registered in any PLMN. This parameter is only included in a Request/Indication when the parameter Subscriber Status is set to the value Operator Determined Barring. Note that all General Operator Determined Barring Categories shall be set to their actual status.

If the VLR or the SGSN receives an Indication containing Operator Determined Barring General Data which shows that the subscriber is subject to barring not supported / not allocated by the VLR or by the SGSN, it returns Operator Determined Barring General Data in the response to the HLR to show the barring categories which are not supported / not allocated by the VLR or by the SGSN. This parameter is used by the VLR and the SGSN.

Operator Determined Barring HPLMN data

It includes all the Operator Determined Barring categories that may be applied only to a subscriber registered in the HPLMN. Therefore, it shall only be transferred to the VLR or to the SGSN when the subscriber is roaming into the HPLMN and when the parameter Subscriber Status is set to the value Operator Determined Barring. Note that all HPLMN Operator Determined Barring Categories shall be set to their actual status.

If Subscriber Status is set to the value Operator Determined Barring and no Operator Determined Barring HPLMN data is present then the VLR or the SGSN shall not apply any HPLMN specific ODB services to the subscriber. This parameter is used by the VLR and the SGSN.

eMLPP Subscription Data

If included in the Insert Subscriber Data request this parameter defines the priorities the subscriber might apply for a call (as defined in subclause 7.6). It contains both subparameters of eMLPP.

If the VLR does not support the eMLPP service it returns its code to the HLR in the parameter SS-Code List and therefore discards the received information (no error is sent back).

eMLPP subscription data that have been stored previously in a subscriber data record in the VLR are completely replaced by the new eMLPP subscription data received in a MAP_INSERT_SUBSCRIBER_DATA during either an Update Location or Restore Data procedure or a stand alone Insert Subscriber data procedure. This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it.

Roaming Restriction Due To Unsupported Feature

The HLR may decide to include this parameter in the request if certain services or features are indicated as not supported by the MSC/VLR (e.g. Advice of Charge Charging Level).

If this parameter is sent to the VLR the MSC area is restricted by the HLR and the VLR. This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it.

Regional Subscription Data

If included in the Insert Subscriber Data request this parameter defines the subscriber’s subscription area for the addressed VLR or for the addressed SGSN (as defined in subclause 7.6). It contains the complete list of up to 10 Zone Codes that apply to a subscriber in the currently visited PLMN. The HLR shall send only those Zone Codes which are stored against the CC and NDC of the VLR or the CC and NDC of the SGSN to be updated.

NOTE: Support of this parameter is a network operator option and it will not be sent to networks which do not support Regional Subscription.

Regional subscription data that have been stored previously in a subscriber data record in the VLR or in the SGSN are completely replaced by the regional subscription data received in an Insert Subscriber Data indication during either an Update Location or Restore Data procedure or a stand alone Insert Subscriber data procedure.

After the regional subscription data are inserted the VLR or the SGSN shall derive whether its location areas are allowed or not. If the whole MSC or SGSN area is restricted it will be reported to HLR by returning the Regional Subscription Response.

The VLR or the SGSN returns a Regional Subscription Response indicating that a problem with the Zone Code has been detected in one of the following cases:

– Too Many Zone Codes: more than 10 Zone Codes are to be stored in the VLR or in the SGSN;

– Regional Subscription Not Supported by the VLR or the SGSN;

– Zone Codes Conflict: the VLR or the SGSN detects that the zone codes indicate conflicting service permission for a location area.

Zone codes which have no mapping to location areas shall be ignored.

If a sequence of MAP_INSERT_SUBSCRIBER_DATA services is used during a dialogue, Regional Subscription Data shall be accepted only in one service. Regional Subscription Data received in a subsequent service shall be rejected with the error Unexpected Data Value.

If Regional Subscription Data are not included in any MAP_INSERT_SUBSCRIBER_DATA service, there is no restriction of roaming due to Regional Subscription. This parameter is used by the VLR and the SGSN.

Voice Broadcast Data

This parameter contains a list of group id’s a user might have subscribed to; (VBS-Data is defined in subclause 7.6). It includes VBS information either at location updating or at restoration or when it is changed.

At location updating, restoration or when there is a change in VBS data, the HLR shall include the complete VBS-Data.

When the VLR receives VBS-Data within a dialogue it shall replace the stored VBS-data with the received data set. All subsequent VBS-dta received within this dialogue shall be interpreted as add-on data.

If VBS-data is omitted in the Insert Subscriber Data operation the VLR shall keep the previously stored VBS data.

If the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. . This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it.

Voice Group Call Data

This parameter contains a list of group id’s a user might have subscribed to; see subclause 7.6.

At location updating, restoration or when there is a change in VGCS data, the HLR shall include the complete VGCS-Data.

When the VLR receives VGCS-Data within a dialogue it shall replace the stored VGCS-Data with the received data set. All VGCS-Data received within this dialogue shall be interpreted as add-on data.

If VBCS-Data is omitted in the Insert Subsciber Data operation the VLR shall keep the previously stored VGCS-Data.

If the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it.

North American Equal Access preferred Carrier Id

The preferred carrier identity that is subscribed to.

When the VLR receives this parameter from the HLR, it shall replace the previously stored preferred carrier identity with the received one.

SS-Code List

The list of SS-Code parameters that are provided to a subscriber but are not supported/allocated by the VLR (SS-Code is defined in subclause 7.6). The list can only include individual SS-Codes that were sent in the service request. This parameter is used only by the VLR.

Regional Subscription Response

If included in the response this parameter indicates one of:

– MSC Area Restricted entirely because of regional subscription;

– SGSN Area Restricted entirely because of regional subscription;

– Too Many Zone Codes to be inserted;

– Zone Codes Conflict;

– Regional Subscription not Supported by the VLR or by the SGSN.

If the VLR determines after insertion of Regional Subscription Data that the entire MSC area is restricted, the VLR shall respond with a Regional Subscription Response indicating MSC Area Restricted. Otherwise MSC Area Restricted is not sent. The HLR shall check whether the current MSC area is no longer restricted.

If the SGSN determines after insertion of Regional Subscription Data that the entire SGSN area is restricted, the SGSN shall respond with a Regional Subscription Response indicating SGSN Area Restricted. Otherwise SGSN Area Restricted is not sent. The HLR shall check whether the current SGSN area is no longer restricted. This parameter is used by the VLR and by the SGSN.

VLR CAMEL Subscription Info

This parameter is sent for subscribers who have CAMEL services which are invoked in the MSC. In CAMEL phase 1 this parameter contains only the O-CSI. In CAMEL Phase 2 this parameter contains the SS-CSI and/or the O-CSI. If an O-CSI is contained, TDP-Criteria may also be present in CAMEL Phase 2. The VLR CAMEL Subscription Info is sent at location updating or when any information in the applicable CAMEL Subscription Info in the HLR has been changed. The entire set of CAMEL Subscription Info is sent within one dialogue. If a set of CAMEL Subscription Info is already stored in the VLR, i.e received within a previous dialogue, it is replaced by the received data. If the VLR CAMEL Subscription Info is omitted in the Insert Subscriber Data operation the VLR shall keep the previously stored VLR CAMEL Subscription Info. Within one dialogue subsequent received data are interpreted as add-on data. If the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value.This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it.

Supported CAMEL Phases

The use of this parameter and the requirements for its presence are specified in GSM 03.78. This parameter is used only by the VLR.

A VLR not supporting any CAMEL Phase may omit this parameter.

GPRS Subscription Data

This parameter contains a list of PDP-contexts a user has subscribed to; see subclause 7.6.

At GPRS location updating the HLR shall include the complete GPRS Subscription Data.

When there is a change in GPRS subscriber data the HLR shall include only the new and/or modified PDP contexts.

When the SGSN receives GPRS Subscription Data within a dialogue it shall check if the received data has to be considered as the entire GPRS subscription data. If so, it shall replace the stored GPRS Subscription Data with the received data set, otherwise it shall replace the data only for the modified PDP contexts (if any) and add the new PDP contexts (if any) to the stored GPRS Subscription Data.

If GPRS Subscription Data is omitted in the Insert Subscriber Data operation the SGSN shall keep the previously stored GPRS Subscription Data.

If the SGSN detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. This parameter is used only by the SGSN and if the VLR receives this parameter it shall ignore it.

Roaming Restricted In SGSN Due To Unsupported Feature

The HLR may decide to include this parameter in the request if certain services or features are indicated as not supported by the SGSN. This parameter is used only by the SGSN and if the VLR receives this parameter it shall ignore it.

User error

Only one of the following values is applicable:

– Unidentified subscriber;

– Data missing;

– Unexpected data value.

8.8.1.4 Basic service information related to supplementary services

A number of parameters that relate to supplementary services can be qualified by a Basic Service Group (or a Basic Service Group List). This subclause explains how this information is to be interpreted. Supplementary service parameters to which this subclause is applicable only apply to the basic service groups described in this subclause, and only those basic service groups shall be overwritten at the VLR.

The Basic Service Group (or Basic Service Group List) is optional.

If present the Basic Service Group (or the elements of the Basic Service Group List) shall be one of:

– an Elementary Basic Service Group for which the supplementary service is applicable to at least one basic service in the group; and to which the subscriber has a subscription to at least one basic service in the group;

– the group "All Teleservices" provided that the service is applicable to at least one teleservice and that the subscriber has a subscription to at least one teleservice that is in the same Elementary Basic Service Group as a teleservice to which the service is applicable;

– the group "All Bearer Services" provided that the service is applicable to at least one bearer service and that the subscriber has a subscription to at least one bearer service that is in the same Elementary Basic Service Group as a basic service to which the service is applicable.

If the Basic Service Group (or Basic Service Group List) is not present then the parameter shall apply to all Basic Service Groups.

If the basic service information is not a single Elementary Basic Service Group then the parameter shall be taken as applying individually to all the Elementary Basic Service Groups for which:

– the supplementary service is applicable to at least one basic service in the Basic Service Group; and

– the subscriber has a subscription to at least one basic service in the Basic Service Group.

The VLR is not required to store supplementary services data for Basic Service Groups that are not supported at the VLR.

8.8.2 MAP-DELETE-SUBSCRIBER-DATA service

8.8.2.1 Definition

This service is used by an HLR to remove certain subscriber data from a VLR if the subscription of one or more supplementary services or basic services is withdrawn. Note that this service is not used in case of erasure or deactivation of supplementary services.

Also this service is used by an HLR to remove GPRS subscription data from a SGSN.

It is a confirmed service and consists of the primitives shown in table 8.8/2.

8.8.2.2 Service primitives

Table 8.8/2: MAP-DELETE-SUBSCRIBER-DATA

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

IMSI

M

M(=)

Basic service List

C

C(=)

SS-Code List

C

C(=)

Roaming Restriction Due To

Unsupported Feature

C

C(=)

Camel Subscription Info Withdraw

C

C(=)

Regional Subscription Data

C

C(=)

VBS Group Indication

C

C(=)

VGCS Group Indication

C

C(=)

GPRS Subscription Data Withdraw

C

C(=)

Roaming Restricted In SGSN Due To Unsupported Feature

C

C(=)

Regional Subscription Response

C

C(=)

User error

C

C(=)

Provider error

O

8.8.2.3 Parameter use

All parameters are described in subclause 7.6. The following clarifications are applicable:

Basic service List

A list of Extensible Basic service parameters (Extensible Basic service is defined in subclause 7.6). It is used when one, several or all basic services are to be withdrawn from the subscriber. If the VLR or the SGSN receives a value for an Extensible Basic Service which it does not support, it shall ignore that value. This parameter is used by the VLR and by the SGSN.

SS-Code List

A list of SS-Code parameters (SS-Code is defined in subclause 7.6). It is used when several or all supplementary services are to be withdrawn from the subscriber.

There are three possible options:

– deletion of basic service(s);

The parameter Basic service List is only included.

– deletion of supplementary service(s);

The parameter SS-Code List is only included.

– deletion of basic and supplementary services;

Both Basic service List and SS-Code List are included.

This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it.

Roaming Restriction Due To Unsupported Feature

This parameter is used if Roaming Restriction Due To Unsupported Feature is deleted from the subscriber data. This may occur if unsupported features or services are removed from the subscriber data in the HLR.

If this parameter is sent the VLR shall check if the current Location Area is possibly allowed now. This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it.

CAMEL Subscription Info Withdraw

This parameter is used to indicate that CAMEL Subscription Info shall be deleted from the VLR. All CAMEL Subscription Info for the subscriber shall be deleted. This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it.

Regional Subscription Identifier

Contains one single Zone Code (as defined subclause 7.6) and is used if all Zone Codes shall be deleted from the subscriber data. When all the Zone Codes are deleted, the VLR or the SGSN shall check for its location areas whether they are allowed or not. If the whole MSC area is restricted, VLR will report it to HLR by returning the Regional Subscription Response "MSC Area Restricted". If the whole SGSN area is restricted, SGSN will report it to HLR by returning the Regional Subscription Response "SGSN Area Restricted".

The binary coding of the Zone Code value received in a Delete Subscriber Data request shall not be checked by the VLR or by the SGSN.

Note that support of this parameter is a network operator option and it shall not be sent to networks which do not support Regional Subscription.

If Regional Subscription is not supported by the VLR or by the SGSN, the request for deletion of Zone Codes is refused by sending the Regional Subscription Response "Regional Subscription Not Supported" to the HLR.

If no Zone Codes are stored in the respective subscriber data record, the request for deleting all Zone Code information shall be ignored and no Regional Subscription Response shall be returned. This parameter is used by the VLR and by the SGSN.

VBS Group Indication

Contains an indication (flag) which is used if all Group Id’s shall be deleted from the subscriber data for the Voice Broadcast teleservice.

If VBS is not supported in the VLR or no Group Ids are stored for VBS in the respective subscriber record, the request for deletion of all Group Ids shall be ignored. This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it.

VGCS Group Indication

Contains an indication (flag) which is used if all Group Id’s shall be deleted from the subscriber data for the Voice Group Call teleservice. This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it.

If VGCS is not supported in the VLR or no Group Ids are stored for VGCS in the respective subscriber record, the request for deletion of all Group Ids shall be ignored.

GPRS Subscription Data Withdraw

This parameter is used to indicate whether all GPRS Subscription Data for the subscriber shall be deleted or if only a subset of the stored GPRS Subscription Data for the subscriber shall be deleted. In the latter case only those PDP context whose identifiers are included in the subsequent identifier list will be deleted. This parameter is used only by the SGSN and if the VLR receives this parameter it shall ignore it.

Roaming Restricted In SGSN Due To Unsupported Feature

This parameter is used if Roaming Restricted In SGSN Due To Unsupported Feature is deleted from the GPRS subscriber data. This may occur if unsupported features or services are removed from the GPRS subscriber data in the HLR.

If this parameter is sent the SGSN shall check if the current Location Area is possibly allowed now. This parameter is used only by the SGSN and if the VLR receives this parameter it shall ignore it.

Regional Subscription Response

If included in the Delete Subscriber Data response this parameter indicates one of:

– MSC Area Restricted

– SGSN Area Restricted;

– Regional Subscription Not Supported.

This parameter is used by the VLR and by the SGSN.

User error

Only one of the following values is applicable:

– Unidentified subscriber;

– Data missing;

– Unexpected data value.

8.9 Identity management services

8.9.1 MAP-PROVIDE-IMSI service

8.9.1.1 Definition

This service is used by a VLR in order to get, via the MSC, the IMSI of a subscriber (e.g. when a subscriber has identified itself with a TMSI not allocated to any subscriber in the VLR).

It is a confirmed service and consists of the primitives shown in table 8.9/1.

8.9.1.2 Service primitives

Table 8.9/1: MAP-PROVIDE-IMSI

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

IMSI

C

C(=)

User error

C

C(=)

Provider error

O

8.9.1.3 Parameter use

All parameters are described in subclause 7.6. The following clarifications are applicable:

IMSI

This parameter is received when the request is successfully carried out. It contains the requested IMSI.

User error

Only one of the following values is applicable:

– Absent subscriber.

8.9.2 MAP-FORWARD-NEW-TMSI service

8.9.2.1 Definition

This service is used by a VLR to allocate, via MSC, a new TMSI to a subscriber during an ongoing transaction (e.g. call set-up, location updating or supplementary services operation).

It is a confirmed service and consists of the primitives shown in table 8.9/2.

8.9.2.2 Service primitives

Table 8.9/2: MAP-FORWARD-NEW-TMSI

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

TMSI

M

M(=)

Provider error

O

8.9.2.3 Parameter use

The parameter TMSI is described in subclause 7.6.

8.10 Fault recovery services

8.10.1 MAP_RESET service

8.10.1.1 Definition

This service is used by the HLR, after a restart, to indicate to a list of VLRs or SGSNs that a failure occurred.

The MAP_RESET service is a non-confirmed service using the service primitives defined in table 8.10/1

8.10.1.2 Service primitives

Table 8.10/1: MAP_RESET

Parameter name

Request

Indication

Invoke Id

M

M(=)

HLR number

M

M(=)

HLR Id LIST

U

C(=)

8.10.1.3 Parameter definition and use

Invoke Id

See definition in subclause 7.6.1.

HLR number

See definition in subclause 7.6.2.

HLR Id LIST

The HLR Id List is a list of HLR Id. If the parameter is present in the indication, the VLR or SGSN may base the retrieval of subscribers to be restored on their IMSI: the subscribers affected by the reset are those whose IMSI leading digits are equal to one of these numbers. If the parameter is absent, subscribers to be restored are those for which the OriginatingEntityNumber received at location updating time matches the equivalent parameter of the Reset Indication.

8.10.2 MAP_FORWARD_CHECK_SS_INDICATION service

8.10.2.1 Definition

This service may be used by an HLR as an implementation option, to indicate to a mobile subscriber that supplementary services parameters may have been altered, e.g. due to a restart. If received from the HLR, the VLR shall forward this indication to the MSC, which in turn forwards it to the MS. The HLR only sends this indication after successful completion of the subscriber data retrieval from HLR to VLR that ran embedded in a MAP_UPDATE_LOCATION procedure.

The MAP_FORWARD_CHECK_SS_INDICATION service is a non-confirmed service using the service primitives defined in table 8.10/2.

8.10.2.2 Service primitives

Table 8.10/2: MAP_FORWARD_CHECK_SS_INDICATION

Parameter name

Request

Indication

Invoke Id

M

M(=)

8.10.2.3 Parameter definition and use

Invoke Id

See definition in subclause 7.6.1.

8.10.3 MAP_RESTORE_DATA service

8.10.3.1 Definition

This service is invoked by the VLR on receipt of a MAP_PROVIDE_ROAMING_NUMBER indication for an unknown IMSI, or for a known IMSI with the indicator "Confirmed by HLR" set to "Not confirmed". The service is used to update the LMSI in the HLR, if provided, and to request the HLR to send all data to the VLR that are to be stored in the subscriber’s IMSI record.

The MAP_RESTORE_DATA service is a confirmed service using the service primitives defined in table 6.10/3.

8.10.3.2 Service primitives

Parameter name

Request

Indication

Response

Confirm

Invoke Id

M

M(=)

M(=)

M(=)

IMSI

M

M(=)

LMSI

U

C(=)

Supported CAMEL phases

C

C(=)

HLR number

C

C(=)

MS Not Reachable Flag

C

C(=)

User error

C

C(=)

Provider error

O

Table 8.10/3: MAP_RESTORE_DATA

8.10.3.3 Parameter definitions and use

Invoke Id

See definition in subclause 5.6.1.

IMSI

See definition in subclause 5.6.2.

LMSI

See definition in subclause 5.6.2. It is an operator option to provide the LMSI from the VLR; it is mandatory for the HLR to support the LMSI handling procedures.

Supported CAMEL Phases

This parameter indicates which phases of CAMEL are supported. Must be present if a CAMEL phase different from phase 1 is supported. Otherwise may be absent.

HLR number

See definition in subclause 5.6.2. The presence of this parameter is mandatory in case of successful outcome of the service.

MS Not Reachable Flag

See definition in subclause 5.6.8. This parameter shall be present in case of successful outcome of the service, if the "MS Not Reachable flag" was set in the HLR.

User error

In case of unsuccessful outcome of the service, an error cause shall be returned by the HLR. The following error causes defined in subclause 5.6.1 may be used, depending on the nature of the fault:

– unknown subscriber;

– system failure;

– unexpected data value;

– data missing.

Provider error

For definition of provider errors see subclause 5.6.1.

8.11 Subscriber Information services

8.11.1 MAP-ANY-TIME-INTERROGATION service

8.11.1.1 Definition

This service is used by the gsmSCF, to request information (e.g. subscriber state and location) from the HLR at any time.

8.11.1.2 Service primitives

Table 8.11/1: Any_Time_Interrogation

Parameter name

Request

Indication

Response

Confirm

Invoke id

M

M(=)

M(=)

M(=)

Requested Info

M

M(=)

gsmSCF-Address

M

M(=)

IMSI

C

C(=)

MSISDN

C

C(=)

Location Information

C

C(=)

Subscriber State

C

C(=)

User error

C

C(=)

Provider error

O

8.11.1.3 Parameter definition and use

All parameters are described in subclause 7.6.

The HLR may be able to use the value of the parameter gsmSCF-address to screen an MAP_Any_Time_Interrogation indication.

The use of the parameters and the requirements for their presence are specified in GSM 03.78.

User error

This parameter is sent by the responder when an error is detected and if present, takes one of the following values:

– System Failure;

– Any Time Interrogation Not Allowed;

– Data Missing;

– Unexpected Data Value;

– Unknown Subscriber.

Provider error

This is defined in subclause 7.6.1.

8.11.2 MAP-PROVIDE-SUBSCRIBER-Info service

8.11.2.1 Definition

This service is used to request information (e.g. subscriber state and location) from the VLR at any time.

8.11.2.2 Service primitives

Table 8.11/2: Provide_Subscriber_Information

Parameter name

Request

Indication

Response

Confirm

Invoke id

M

M(=)

M(=)

M(=)

Requested Info

M

M(=)

IMSI

M

M(=)

LMSI

U

O

Location Information

C

C(=)

Subscriber State

C

C(=)

User error

C

C(=)

Provider error

O

8.11.2.3 Parameter definition and use

All parameters are defined in section 7.6. The use of these parameters and the requirements for their presence are specified in GSM 03.18

User error

This parameter is sent by the responder when an error is detected and if present, takes one of the following values:

– Data Missing;

– Unexpected Data Value.

Provider error

This is defined in subclause 7.6.1.