3 Interworking in the MSC, Transparent case

09.103GPPTS

3.1 General

When the MSC receives a forward message from the BSS (possibly forwarded transparently from the MS), it will invoke the desired MAP service and establish a cross reference between the BSSAP procedure and the MAP procedure in order to return the result of the operation to the BSS (which may forward it transparently to the MS. The cross reference is deleted when the MSC terminates the MAP procedure.

Positive or negative results of the MAP procedure are returned in the appropriate BSSAP message.

The parameters of the forward BSSAP message are mapped by a one-to-one mapping into the parameters of the MAP service. However, in some cases parameters received on the radio path may be suppressed at the MSC because they are related to another protocol entity, e.g. information related to RR-management may be included in MM-management messages. Similarly, parameters received in the (positive) MAP service response are mapped one-to-one into parameters of the corresponding backward BSSAP message.

A negative outcome, as carried in various MAP services (MAP specific service response, MAP_U_ABORT, MAP_P_ABORT, MAP_NOTICE and premature MAP_CLOSE, see GSM 09.02 for definitions) is mapped into a cause value in the required backward BSSAP message. In this case several negative results of MAP may be mapped into the same BSSAP cause value, i.e. without discrimination between these negative results.

NOTE: For O & M purposes, the MAP procedure entity in the MSC may require a more detailed overview of negative results than the MS.

These principles are illustrated in figure 1.

04.08 (08.08) MAP service

forward message request

————> ———–>

+———–+ +———+

|information| |parameter|

| element | | |

+———–+ one-to-one +———+

+—–>——————————–>—-+

mapping

MAP service

positive ack response

<———— <———–

+———–+ +———+

|information| |parameter|

| element | | |

+———–+ one-to-one +———+

+—–<——————————–<—-+

mapping

negative

negative cause response

<———— <———–

+———–+ +———+

| cause | | cause |

+———–+ one-to-one or many-to-one +———+

+—–<——————————–<—-+

mapping

Figure 1: Illustration of mapping principles in the MSC

For each of the transparent operations listed in subclause 2.1, the following format is used to show the mapping.

—————————————————————-

| 04.08 or 08.08 09.02 |Notes

——–┼————————————————-┼—–

Forward | MS/BSS to MSC MSC to VLR |

message | message name MAP service request |

| information element 1 <—> parameter 1 |

| information element 2 <—> parameter 2 |

——–┼————————————————-┼—–

Positive| MSC to MS/BSS VLR to MSC |

result | message name positive response |

| information element 1 <—> parameter 1 |

| information element 2 <—> parameter 2 |

——–┼————————————————-┼—–

Negative| MSC to MS/BSS VLR to MSC |

result | message name negative response |

| cause 1 <—> cause 1 |

| cause 2 <—> cause 2 |

| cause 3 <—> MAP_U/P_ABORT |

| cause 3 <—> MAP_NOTICE |

| cause 3 <—> MAP_CLOSE |

——–┴————————————————-┴—–

Equivalent mapping principles apply for operations invoked by the VLR towards the BSS/MS. However, negative results are generally not received from the BSS/MS but are generated in the MSC. Therefore, for such operations the interworking for negative results is not normally shown.

3.2 Location area updating

—————————————————————

| 08.08/04.08 09.02 |Notes

——–┼————————————————┼—–

Forward | COMPLETE LAYER 3 INFO MAP_UPDATE_LOCATION_ |

message | (LOCATION UPDATING AREA request |

| REQUEST) |

| |

| Location area id Previous LA Id |

| Mobile identity IMSI or TMSI |

| Mobile station |

| classmark 1 – | 4

| Ciphering key CKSN |

| seq number |

| Location update Location update |

| type type | 3

| Cell identifier Target LA Id | 1

| Chosen channel – |

——–┼————————————————┼—–

Positive| DTAP (LOCATION MAP_UPDATE_LOCATION |

results | UPDATING ACCEPT) AREA response |

| |

| Location area identity – |

| Mobile identity – | 5

| Follow on proceed – |

——–┼————————————————┼—–

Negative| DTAP (LOCATION MAP_UPDATE_LOCATION |

results | UPDATING REJECT) AREA response |

| |

| IMSI unknown in HLR Unknown subscriber | 6

| Network failure Unknown LA | 2

| Roaming not allowed: |

| PLMN not allowed PLMN not allowed |

| LA not allowed LA not allowed |

| Roaming not National Roaming |

| allowed in this LA not allowed |

| PLMN not allowed Operator |

| determined barring|

| Illegal MS Illegal subscriber |

| Illegal ME Illegal equipment |

| Network failure System Failure |

| Network failure Unexpected data value|

| Network failure MAP_U/P_ABORT |

| Network failure MAP_NOTICE |

| Network failure MAP_CLOSE |

——–┴————————————————┴—–

NOTE 1: The Target LA Id parameter is derived by the MSC from the Cell identifier information element.

NOTE 2: The Unknown LA error is only generated as a result of incorrect information being inserted by the MSC or BSS.

NOTE 3: This parameter can be used by the VLR to decide whether (e.g.) Authentication or IMEI checking is needed.

NOTE 4 As the mobile station classmark (1 or 2) is received by the MSC at the establishment of every RR connection, this information need not be stored in the VLR, but it is stored in the MSC as long as the RR connection exists.

NOTE 5 The mobile identity is inserted by the MSC if it is received in a MAP_FORWARD_NEW_TMSI service. If a TMSI is included, the MS should respond with a TMSI REALLOCATION COMPLETE message.

NOTE 6 The HLR shall also send this error if there is an error in the type of subscription (i.e. VLR requests service for a GPRS only subscriber)

3.3 Detach IMSI

—————————————————————

| 04.08 09.02 |Notes

——–┼————————————————┼—–

Forward | IMSI DETACH MAP_DETACH_IMSI |

message | INDICATION request |

| |

| Mobile identity IMSI or TMSI |

| |

| Mobile Station |

| classmark 1 – |

——–┼————————————————┼—–

Positive| |

result | | 1

——–┼————————————————┼—–

Negative| |

result | |

——–┴————————————————┴—–

NOTE 1: The forward message is not acknowledged.

Depending on the state of the MS, the IMSI DETACH INDICATION may be carried in either a DTAP message or a BSSMAP COMPLETE LAYER 3 INFORMATION message.

3.4 Routeing area updating

—————————————————————

| 04.08 09.02 |Notes

——–┼————————————————┼—–

Forward | GMM (ROUTEING AREA MAP_UPDATE_GPRS _ |

message | UPDATE REQUEST) LOCATION request |

| |

| MS classmark 1 – |

| MS classmark 4 – |

| GPRS Ciphering – |

| key seq number |

| Mobile station IMSI |

| identity |

| Old routeing area – |

| identification |

——–┼————————————————┼—–

Positive| GMM (ROUTEING AREA MAP_UPDATE_GPRS |

results | UPDATE ACCEPT) LOCATION response |

| |

| Routeing area – |

| identification |

| Mobile station – | 1

| identity |

| C Mobile station – | 2

| C Reject: IMSI unknown – | 3

| in HLR |

| C Reject: MSC temporarily – | 4

| not reacheable |

——–┼————————————————┼—–

Negative| GMM (ROUTEING AREA MAP_UPDATE_GPRS |

results | UPDATE REJECT) LOCATION response |

| |

| Network failure – | 5

| GPRS services Unknown HLR |

| not allowed in |

| this PLMN |

| GPRS services Unknown subscriber | 6

| not allowed (no GPRS subscription) |

| GPRS services and Unknown subscriber | 7

| non GPRS services (IMSI unknown) |

| not allowed |

| C GPRS services Unknown subscriber | 8

| not allowed (no GPRS subscription) |

| C GPRS services and Unknown subscriber | 9

| non-GPRS services (IMSI unknown) |

| not allowed |

| MS identity cannot – | 10

| be derived by |

| the network |

| Roaming not allowed: |

| GPRS services not PLMN not allowed |

│ allowed in this │

│ PLMN │

| LA not allowed – |

| Roaming not allowed – |

| in this LA |

| GPRS services not Operator |

| allowed in this determined barring|

│ PLMN │

| Illegal MS – |

| Illegal ME – |

| Network failure System Failure |

| Network failure Unexpected data value|

| Network failure MAP_U/P_ABORT |

| Network failure MAP_NOTICE |

| Network failure MAP_CLOSE |

——–┴————————————————┴—–

NOTE 1: The mobile station identity is inserted by the SGSN if the SGSN wants to deallocate or re-allocate a P-TMSI. If the SGSN wants to deallocate the P-TMSI it shall include the IMSI. If the SGSN wants to re-allocate the P-TMSI it shall include the new P-TMSI. If a P-TMSI is included, the MS shall respond with a ROUTEING AREA UPDATE COMPLETE message.

NOTE 2: The mobile station identity is inserted by the SGSN if it is received in a BSSAP+ LOCATION UPDATE ACCEPT message from the VLR. If a TMSI is included, the MS shall respond with a ROUTEING AREA UPDATE COMPLETE message. Only used in the Combined Routeing and Location Area procedure.

NOTE 3: This reject cause is inserted on the positive response by the SGSN if the SGSN receives a BSSAP+ LOCATION UPDATE REJECT message from the VLR indicating in the reject cause IMSI unknown in HLR. Only used in the Combined Routeing and Location Area procedure.

NOTE 4: This reject cause is inserted on the positive response by the SGSN if the SGSN does not receive any response from the VLR to a previous BSSAP+ LOCATION UPDATE REQUEST message. Only used in the Combined Routeing and Location Area procedure.

NOTE 5: The Unknown RA error is only generated as a result of incorrect information being inserted by the BSS.

NOTE 6: The HLR shall send Unknown subscriber with diagnostic value No GPRS subscription if the HLR indicates that there is an error in the type of subscription (i.e. SGSN requests service for a non-GPRS only subscriber).

NOTE 7: The HLR shall send Unknown subscriber with diagnostic value IMSI unknown if the HLR indicates that the IMSI provided by the SGSN is unknown.

NOTE 8: The HLR shall send Unknown subscriber with diagnostic value No GPRS subscription if the HLR indicates that there is an error in the type of subscription (i.e. SGSN requests service for a non-GPRS only subscriber). Used in the Combined Routeing and Location Area procedure.

NOTE 9: This reject cause is inserted if the SGSN receives a MAP GPRS UPDATE LOCATION negative response message indicating IMSI unknown. Used in the Combined Routeing and Location Area procedure.

NOTE 10: This reject cause is inserted if the SGSN does not receive any response from the old SGSN to a previous SGSN CONTEXT REQUEST message.

3.5 Authentication

The message flow for the authentication procedure is shown in figure 2.

MS MSC VLR

MAP_AUTHENTICATE request

AUTHENTICATION REQUEST <———————————-

<———————–

AUTHENTICATION RESPONSE

———————–> MAP_AUTHENTICATE response

———————————->

or

MAP_U/P_ABORT

———————————->

Figure 2: Authentication operation

The MSC can only act on a MAP_AUTHENTICATE request if an RR connection exists with the MS. If such a connection does not exist, the MSC shall terminate the MAP procedure with a MAP_U_ABORT. The same applies if the MS does not respond to an AUTHENTICATION REQUEST message.

—————————————————————

| 04.08 09.02 |Notes

——–┼————————————————┼—–

Forward | AUTHENTICATION REQUEST MAP_AUTHENTICATE |

message | request |

| |

| RAND RAND |

| |

| Ciphering key seq CKSN |

| number |

——–┼————————————————┼—–

Backward| AUTHENTICATION REQUEST MAP_AUTHENTICATE |

result | response |

| |

| SRES SRES |

——–┴————————————————┴—–

If the SRES parameter does not match the value stored in the VLR, then the ongoing MAP procedure shall be terminated with a cause ‘illegal subscriber’. This shall cause the MSC to send an AUTHENTICATION REJECT message.

3.6 Retrieval of the IMSI from the MS

The VLR may request open identification of an MS with a MAP_PROVIDE_IMSI request.

The mapping of information elements is as follows:

—————————————————————

| 04.08 09.02 |Notes

——–┼————————————————┼—–

Forward | IDENTITY REQUEST MAP_PROVIDE_IMSI |

message | request |

| Identity type |

| set to: IMSI | 1

——–┼————————————————┼—–

Backward| IDENTITY RESPONSE MAP_PROVIDE_IMSI |

result | Mobile Identity (IMSI) response |

——–┴————————————————┴—–

NOTE 1: The INVOKE does not carry any parameters. The identity type is inferred from the invoke name.

The MSC shall return a MAP_PROVIDE_IMSI response with user error "absent subscriber" if:

– there is no RR connection with the MS when the MAP service request is received;

– there is no response from the MS.

3.7 Reallocation of TMSI

This operation is invoked by the VLR. The MAP_FORWARD_NEW_TMSI request contains the new TMSI which is forwarded to the MS in the TMSI REALLOCATION COMMAND. When the MS acknowledges the receipt of the new TMSI, the MSC will return a MAP_FORWARD_NEW_TMSI response to the VLR.

If there is no radio connection to the MS when the MSC receives the MAP service request, the MSC shall ignore the message.

—————————————————————

| 04.08 09.02 |Notes

——–┼————————————————┼—–

Forward | TMSI REALLOCATION MAP_FORWARD_NEW_TMSI |

message | COMMAND request |

| |

| Mobile identity TMSI |

| |

| Location area |

| identification – |

——–┼————————————————┼—–

Backward| TMSI REALLOCATION MAP_FORWARD_NEW_TMSI |

result | COMPLETE response |

——–┴————————————————┴—–

3.8 Retrieval of the IMEI from the MS

The VLR may use the MAP_OBTAIN_IMEI service to request the MS to supply its IMEI , or may use the MAP_CHECK_IMEI service to request the MSC to check the MS’s IMEI. For either MAP service the BSSAP signalling is the same.

The mapping of information elements is as follows:

—————————————————————

| 04.08 09.02 |Notes

——–┼————————————————┼—–

Forward | (MAP_CHECK_IMEI request |

message | IDENTITY REQUEST ( or |

| (MAP_OBTAIN_IMEI request |

| Identity type |

| set to: IMEI | 1

——–┼————————————————┼—–

Backward| (MAP_CHECK_IMEI response |

result | IDENTITY RESPONSE ( or |

| (MAP_OBTAIN_IMEI response |

| |

| Mobile Identity IMEI | 2

| (IMEI) |

——–┴————————————————┴—–

NOTE 1: The MAP service request does not carry any parameters. The identity type is inferred from the service name.

NOTE 2: If the MAP_CHECK_IMEI service was used, the MSC also returns the equipment status to the VLR in the MAP_CHECK_IMEI response, after a successful dialogue with the EIR using the IMEI received from the MS.

The MSC shall terminate the MAP dialogue with the VLR using a MAP_U_ABORT if:

– there is no RR connection with the MS when the MAP service request is received;

– there is no response from the MS.

NOTE: The MSC can also obtain the IMEI from a phase 2 MS by including appropriate information in the BSSMAP Cipher Mode Command.

3.9 Tracing subscriber activity

The VLR may request the MSC and/or BSS to record data about the current transaction with an MS.

—————————————————————

| 08.08 09.02 |Notes

——–┼————————————————┼—–

Forward | MSC INVOKE TRACE MAP_TRACE_SUBSCRIBER_ |

message | ACTIVITY request |

| |

| Trace type Trace type |

| TriggerId – |

| Trace reference Trace reference |

| TransactionId – |

| Mobile identity(IMSI) IMSI | 1

| Mobile identity(IMEI) IMEI | 1

| OMCId OMCId |

——–┼————————————————┼—–

Backward| none none |

result | |

——–┴————————————————┴—–

NOTE 1: The VLR may provide either an IMSI or IMEI, but not both.