Overview
When analyzing P2P traces from an MNO towards another local operator (B-Party) you observe that all SRI-SM response from this operator is returned with IMSI and LMSI and your SMSC terminates the MT towards the B-party with LMSI instead of IMSI.
You would like to understand why the SMSC used LMSI instead of IMSI and whether this behavior is configurable.
Information
This behavior of the RTR is normal as on the first SRI-SM response from the HLR it receives both the IMSI and the LMSI. Thereafter the RTR performs home routing and sends a scrambled IMSI to the origin SMSC.
After receiving the MTFSM with the scrambled IMSI, the RTR performs the correlation with the info that was first received from the HLR and verifies that there is no violation in this flow, then it forwards the MT using the LMSI that was initially provided by the HLR after the successful correlation.
Note:
- Terminating MT using LMSI is hardcoded and is not configurable. There are no parameters on the system to configure for LMSI usage on MT.
- The parameter
mobNetworkIncludeTcapUserInfois not specifically introduced to control if the RTR should use IMSI or LMSI. As indicated in the operator manual, enabling this parameter will include the TCAP user information "map-open" in the outgoing requests.It happens that in case both LMSI and IMSI are received, the RTR will include the field "destinationReference" using the IMSI value in the map-open part which could be used as a workaround by the customer if they want to apply this for a specific network.
This parameter will only affect the selected network and as mentioned, its objective is to include the map-open user information in the outgoing requests even if the destination network is not using LMSI.
Priyanka Bhotika
Comments