Difference between revisions of "USSD GW"

Revision as of 15:20, 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

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

System description

System design

In order to provide the required functionality, the system makes use of the following YATE components:

• the SS7 stack present in YATE
• the camel_map module which decodes/encodes MAP messages coming from the SS7 network to/from internal YATE messages containing MAP operations in XML form. Together with the SS7 layer this provides MAP connectivity with HLR/gsmSCF.
• the ussd_map module which takes internal MAP messsages decoded by the camel_map moduled and translates them to internal USSD messages.
• the SMPP stack present in YATE which is able to catch internal USSD messages and transmit them over SMPP. It also translates SMPP messages into internal USSD messages.

The project will also make use of the camel_map functionality with the underlying SS7 layer in order to provide MAP connectivity with the HLR/gsmSCF.

Configuration

Monitoring

References

• Mobile Application Part (MAP) specification: ETSI TE 129 002