3 Interworking in the MSC, Transparent case

29.0103GPPInformation element mapping between Mobile Station - Base Station System (MS - BSS) and Base Station System - Mobile-services Switching Centre (BSS - MSC)Release 17Signalling Procedures and the Mobile Application Part (MAP)TS

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 3GPP TS 29.002 [9] 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.

24.008 (48.008) 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 clause 2.1, the following format is used to show the mapping.

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

| 24.008 or 48.008 29.002 |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 Routeing area updating

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

| 24.008 29.002 |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 – | 14

| Roaming not allowed – |

| in this LA |

| No Suitable cells in – | 11

| location area |

| GPRS services not Operator |

| allowed in this determined barring|

│ PLMN │

| GPRS services not – | 12

| allowed in this |

| PLMN |

| C GPRS services not – | 12

| allowed in this |

| PLMN |

| Additional roaming |

| not allowed: | 13

| No Suitable cells in Supported RAT Types |

| location area not allowed |

| 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). The HLR may also send this error in the MAP SEND AUTHENTICATION INFO RESPONSE message.

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. The HLR may also send this error in the MAP SEND AUTHENTICATION INFO RESPONSE message.

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.

NOTE 11: The "No Suitable cells in location area" error is generated when the MS has access to only part of the PLMN e.g. due to Administrative Restriction of Subscribers’ Access, but where there may also be suitable location areas available. The MS retries on another location area. The recommended cause due to Administrative Restriction of Subscriber"s Access is "No Suitable Cells in Location Area", but cause "Roaming Not Allowed in this LA" may also be used, based on operator configuration.

NOTE 12: This reject cause is inserted if the SGSN receives in MAP INSERT SUBSCRIBER DATA message an indication of Roaming restricted in SGSN due to unsupported feature.

NOTE 13: Other reject causes than "no Suitable cells in location area" can be used (e.g. "Roaming not allowed in this location area").

NOTE 14: The cause "LA not allowed" shall be sent only if the HLR indicates that due to subscription to a "regionally restricted service" the MS is not allowed to operate in the location area.

3.3 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.

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

| 24.008 29.002 |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.4 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:

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

| 24.008 29.002 |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.5 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.

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

| 24.008 29.002 |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.6 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:

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

| 24.008 29.002 |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.7 Tracing subscriber activity

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

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

| 48.008 29.002 |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.

3.8 Location update

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

| 24.008 29.002 |Notes

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

Forward | MM (LOCATION UPDATING MAP_UPDATE_LOCATION_ |

message | REQUEST) request |

| |

| Location area id – |

| Mobile identity IMSI |

| Mobile station |

| classmark 1 – |

| Mobile station |

| classmark 2 – |

| Ciphering key – |

| seq number |

| Location update – |

| type |

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

Positive| MM (LOCATION MAP_UPDATE_LOCATION |

results | UPDATING ACCEPT) response |

| |

| Location area identity – |

| Mobile identity – |

| Follow on proceed – |

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

Negative| MM (LOCATION MAP_UPDATE_LOCATION |

results | UPDATING REJECT) response |

| |

| IMSI unknown in HLR Unknown subscriber | 1

| Roaming not allowed: |

| PLMN not allowed PLMN not allowed |

| LA not allowed – | 3

| Roaming not – |

| allowed in this LA |

| No Suitable cells in – |

| location area |

| PLMN not allowed Operator |

| determined barring|

| Additional roaming |

| not allowed: |

| No Suitable cells in Supported RAT Types | 2

| location area not allowed |

| Illegal MS – |

| Illegal ME – |

| Network failure System Failure |

| Network failure Unexpected data value|

| Network failure Data Missing |

| Network failure MAP_U/P_ABORT |

| Network failure MAP_NOTICE |

| Network failure MAP_CLOSE |

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

NOTE 1 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).

NOTE 2: Other reject causes than "no Suitable cells in location area" can be used (e.g. "Roaming not allowed in this location area").

NOTE 3 The VLR shall return the cause "LA not allowed" only if the HLR indicates that due to subscription to a "regionally restricted service" the MS is not allowed to operate in the location area.

If the VLR finds out that the access is denied due to Administrative Restriction of Subscribers" Access based on subscription info received from HLR, VLR will send negative response to the MSC. The MSC will map the received cause using following mapping table:

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

| 24.008 |Notes

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

Negative| MM (LOCATION UPDATE_LOCATION | 1

results | UPDATING REJECT) AREA response |

| |

| PLMN not allowed PLMN not allowed |

| Roaming not National Roaming |

| allowed in this LA not allowed |

| No Suitable cells in RAT not allowed |

| location area |

NOTE 1 The UPDATE LOCATION AREA response refers to the internal interface used between VLR and MSC (see 3GPP TS 23.012 [18]).