Difference between revisions of "USSD GW"
(→MAP USSD description) |
(→MAP USSD description) |
||
Line 25: | Line 25: | ||
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. | 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 | + | 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. |
Identifying parameters in initial request: | Identifying parameters in initial request: | ||
− | + | * ''destinationReference:'' this parameter will contain the MSISDN or IMSI of the user which made the 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. | ||
+ | * ''ussd-DataCodingScheme'': this is a parameter which specifies in which way the ''ussd-String'' parameter is encoded. | ||
== SMPP USSD description == | == SMPP USSD description == |
Revision as of 11:56, 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.
Identifying parameters in initial request:
- destinationReference: this parameter will contain the MSISDN or IMSI of the user which made the 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.
- ussd-DataCodingScheme: this is a parameter which specifies in which way the ussd-String parameter is encoded.