Difference between revisions of "USSD GW"

From ss7api.null.ro
Jump to: navigation, search
(Network initiated USSD requests)
Line 3: Line 3:
 
* redirect USSD requests arriving either from user side or gsmSCF side to a SMPP client where they can be altered.
 
* 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
 
* act as a proxy for requests that need not be handled by SMPP clients or when the SMPP handling fails
 +
  
 
== MAP USSD description ==
 
== MAP USSD description ==
Line 19: Line 20:
  
 
=== Mobile initiated USSD requests ===
 
=== Mobile initiated USSD requests ===
 +
  
 
Mobile initiated USSD requests are USSD requests started by the mobile subscriber.   
 
Mobile initiated USSD requests are USSD requests started by the mobile subscriber.   
Line 29: Line 31:
  
 
=== Network initiated USSD requests ===
 
=== Network initiated USSD requests ===
 +
  
 
Network initiated USSD requests are USSD requests started by the network towards a certain subscriber.
 
Network initiated USSD requests are USSD requests started by the network towards a certain subscriber.
Line 42: Line 45:
  
  
Identifying parameters:
+
=== MAP USSD parameters ===
* ''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.
+
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 ==
 
== SMPP USSD description ==

Revision as of 13:12, 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

Personal tools
Namespaces

Variants
Actions
MAP & CAMEL XML Interface
Diameter XML Interface
MAP and CAMEL operations
Diameter interfaces
Examples
Resources
Navigation
Toolbox