Difference between revisions of "USSD GW"
Line 57: | Line 57: | ||
== Implementation description == | == Implementation description == | ||
+ | |||
+ | == References == | ||
+ | |||
+ | * Mobile Application Part (MAP) specification: ETSI TE 129 002 |
Revision as of 13:22, 7 November 2013
This is an implementation an USSD gateway acting as a MAP Service Control Function (gsmSCF) and as a HLR at the same time. When communicating with a HLR or VLR, the YATE USSD GW acts as a gsmSCF. When communicating with a gsmSCF, the YATE USSDGW acts as a HLR. The purpose of this project is to:
- redirect USSD requests arriving either from user side or gsmSCF side to a SMPP client where they can be altered.
- act as a proxy for requests that need not be handled by SMPP clients or when the SMPP handling fails
Contents |
MAP USSD description
In versions 2 and 3 of the GSM MAP protocol there are 3 operations used for USSD operations
- processUnstructedSS-Request
- unstructuredSS-Request
- unstrusturedSS-Notify
The are 2 scenarios for USSD operations:
- mobile initiated USSD requests
- network initiated USSD requests
A TCAP dialog used by USSD is always terminated by the network side.
Mobile initiated USSD requests
Mobile initiated USSD requests are USSD requests started by the mobile subscriber.
A USSD request is started when receiving a TCAP BEGIN message containing the processUnstructedSS-Request Invoke operation. The request can be handled by the VLR, HLR or a gsmSCF. If the VLR does not handle the request, it will transmit it to the HLR. The HLR can either handle it itself or it can transmit it to a gsmSCF for handling.
At this point, the network can either send a response to the request immediately or request additional information. In the first case, the handler of the request will send a TCAP End with processUnstructuredSS-Request ResultLast containing the result for the request. In the latter case, the network will send a TCAP CONTINUE with unstructuredSS-Request Invoke operation. The response of the mobile subscriber to this request will be passed to the network in a TCAP CONTINUE with unstructuredSS-Request ResultLast component. At this point, if the network decides that it has enough information for providing the response to the user, it will send a TCAP END with processUnstructuredSS-Request ResultLast.
Network initiated USSD requests
Network initiated USSD requests are USSD requests started by the network towards a certain subscriber.
Requests made by the network can be of one of two types:
- user interaction requests
- network notification requests.
User interaction requests are USSD requests that the network makes in which it requires some type of information back from the mobile subscriber. These are started by the network through a TCAP BEGIN containing an unstructuredSS-Request Invoke. The answer from the mobile subscriber will be received in a TCAP CONTINUE containing an unstructuredSS-Request ResultLast. If the network still wants to request further information, it will repeat the process. Otherwise, it will send a TCAP END to close the TCAP dialog.
Network notification requests are USSD requests in which the network only sends a notification to the user. This is achieved through by sending a TCAP BEGIN message containing a unstructuredSS-Notify invoke. The mobile subscriber side will only respond with a TCAP CONTINUE containing an empty unstructuredSS-Notify in order to signal that the notification was received. The network will close the TCAP dialog through TCAP END.
MAP USSD parameters
The following list describe common parameters used across all MAP USSD operations:
- destinationReference: this parameter will contain either an MSISDN or an IMSI. In the case of mobile originated USSD request, this will identify the user which made the request. In the case of network initiated requests, it will identify the mobile user to be contacted for this request.
- ussd-String: for processUnstructuredSS-Request Invoke it contains the dialed USSD code, for the result it would probably contain a message from the network detailing the result of the request. For unstructuredSS-Request Invoke it will contain a message asking for the user to choose some option and for the result it will contain the option chosen by the user. In the case of unstructuredSS-Notify, this parameter will only be present in the Invoke.
- ussd-DataCodingScheme: this is a parameter which specifies in which way the ussd-String parameter is encoded and it is present whenever ussd-String is present. E.g., this parameter would indicate if the ussd-String is encoded using GSM7bit encoding or UCS2.
SMPP USSD description
Implementation description
References
- Mobile Application Part (MAP) specification: ETSI TE 129 002