Вы находитесь на странице: 1из 8

D-USSD_CB-050613-BABT R1.

01

DESCRIPTION

Page 1 of 8

Nobill USSD Callback (Camel) Signalling

Copyright Symsoft AB

Limited

D-USSD_CB-050613-BABT R1.01

DESCRIPTION

Page 2 of 8

Contents
Contents ........................................................................................................................2 Revision history............................................................................................................3 1 2 Description .............................................................................................................3 Signalling sequences..............................................................................................4 2.1 2.2 2.3 Normal Call ......................................................................................................4 Call released due to low balance ......................................................................6 Call rejected with low balance announcement .................................................8

Copyright Symsoft AB

Limited

D-USSD_CB-050613-BABT R1.01

DESCRIPTION

Page 3 of 8

Revision history
Revision R1.00 R1.01 Date 2005-06-13 2005-10-17 Sign BABT BABT Description This is the first revision of the document Invocation of SCP is done before IntitalCallAttempt

Description

The purpose of this document is to describe the detailed network signalling for the Nobill USSD callback service when interworking with an external prepaid system over CAMEL (CAPv2). Nobill communicates with the HLR using MAP (version 2) and with the MSC using INAP/CS1.

Copyright Symsoft AB

Limited

D-USSD_CB-050613-BABT R1.01

DESCRIPTION

Page 4 of 8

2
2.1

Signalling sequences
Normal Call

The sequence below describes the signalling carried out during a normal USSD callback call, i.e. when the initiating user has enough balance on the prepaid account.
Normal call
Calling Party MSC HLR Nobill SCP/PPS Called Party

ProcessUnstructuredSS-Request (1) SendRoutingInfoRequest (2) SendRoutingInfoCnf (3) InitialDP (4) RequestReportBCSMEvent (5) ApplyCharging (6) Continue (7) ProcessUnstructuredSS-RequestResp (8) InitiateCallAttempt (9) RequestReportBCSMEvent (10) Continue (11) "Ringing" (12) "Off-hook" (13) ReportBCSMEvent -- Answer (14) RequestReportBCSMEvent (15) Connect (16) "Ringing" (17) "Off-hook" (18) ReportBCSMEvent -- Answer (19) ReportBCSMEvent -- Answer (20) "On-hook" (21) ReportBCSMEvent -- Disconnect (22) ReportBCSMEvent -- Disconnect (23) ApplyChargingReport (24)

1. An USSD request is received by Nobill from the HLR. The USSD string is on the format *nnn*xxxxxxxx#, where nnn is a configurable service code and xxxxxxxx is the MSISDN of the called party. The MSISDN shall be given in international dialling format, e.g. +46702692431 or 0046702692431.

Copyright Symsoft AB

Limited

D-USSD_CB-050613-BABT R1.01

DESCRIPTION

Page 5 of 8

2. Nobill sends a SendRoutingInfoRequest to the HLR in order to retrieve the roaming number of the initiating party. 3. The HLR responds with roaming number. The O-CSI parameter in the HLR response contains information about the SCP address and the service key. Nobill uses this information when invoking the SCP. 4. Nobill sends an InitialDP request to the PrePaid System (SCP/PPS), i.e. to the SCP. The request is sent over INAP/CAPv2. 5. The PPS sends a RequestReportBSCMEvent request to arm events needed to monitor the call. 6. The PPS sends an ApplyCharging request. Note: Nobill will start a timer supervision and send an ApplyChargingReport when the max call duration specified in the ApplyCharging request has elapsed or when the call is disconnected. 7. The PPS sends a Continue request. 8. An USSD response is sent back to the initiating party displaying a message that the request was received. This USSD session is closed. 9. Nobill sends an InitiateCallAttempt request to the MSC over INAP/CS1 10. Nobill sends a RequestReportBSCMEvent request to the MSC to arm events needed to monitor the call setup. 11. Nobill sends a Continue request to the MSC to order the MSC to continue with the call setup. 12. The MSC setup the call to the initiating party. 13. The initiating party answers the call. 14. The MSC reports the Answer event to Nobill. 15. Nobill sends a Connect request to the MSC to order to connect the called party. 16. The MSC connects the called party. 17. The called party answers 18. The Answer event is reported by the MSC to Nobill. 19. Nobill relays the Answer event to the PPS. 20. Eventually, some of the parties go on-hook. 21. The Disconnect event is reported by the MSC to Nobill. 22. Nobill relays the Disconnect event to the PPS

Copyright Symsoft AB

Limited

D-USSD_CB-050613-BABT R1.01 23. Nobill sends an ApplyChargingReport to the PPS.

DESCRIPTION

Page 6 of 8

2.2

Call released due to low balance

The sequence below describes the signalling carried out when the initiating party runs out of balance during an active call.

1. An USSD request is received by Nobill from the HLR. The USSD string is on the format *nnn*xxxxxxxx#, where nnn is a configurable service code and xxxxxxxx is the MSISDN of the called party. 2. Nobill sends a SendRoutingInfoRequest to the HLR in order to retrieve the roaming number of the initiating party.

Copyright Symsoft AB

Limited

D-USSD_CB-050613-BABT R1.01 3. The HLR responds with roaming number.

DESCRIPTION

Page 7 of 8

4. Nobill sends an InitialDP request to the PrePaid System (PPS), i.e. to the SCP. The request is sent over INAP/CAPv2. 5. The PPS sends a RequestReportBSCMEvent request to arm events needed to monitor the call. 6. The PPS sends an ApplyCharging request. Note: Nobill will start a timer supervision and send an ApplyChargingReport when the max call duration specified in the ApplyCharging request has elapsed or when the call is disconnected.. 7. The PPS sends a Continue request. 8. An USSD response is sent back to the initiating party displaying a message that the request was received. 9. Nobill sends an InitiateCallAttempt request to the MSC over INAP/CS1 10. Nobill sends a RequestReportBSCMEvent request to the MSC to arm events needed to monitor the call setup. 11. Nobill sends a Continue request to the MSC to order the MSC to continue with the call setup. 12. The MSC setup the call to the initiating party. 13. The initiating party answers the call. 14. The MSC reports the Answer event to Nobill. 15. Nobill sends a RequestReportBSCMEvent request to the MSC to arm events needed to monitor the call setup to the called party. 16. Nobill sends a Connect request to the MSC to order to connect the called party. 17. The MSC connects the called party. 18. The called party answers 19. The Answer event is reported by the MSC to Nobill. 20. Nobill relays the Answer event to the PPS. 21. The max call duration, specified in the ApplyCharging request above, has elapsed and Nobill sends an ApplyChargingReport to the PPS. 22. The PPS send a ReleaseCall request. 23. Nobill relays the ReleaseCall request to the MSC.

Copyright Symsoft AB

Limited

D-USSD_CB-050613-BABT R1.01

DESCRIPTION

Page 8 of 8

2.3

Call setup rejected due to low balance

1. An USSD request is received by Nobill from the HLR. The USSD string is on the format *nnn*xxxxxxxx#, where nnn is a configurable service code and xxxxxxxx is the MSISDN of the called party. 2. Nobill sends a SendRoutingInfoRequest to the HLR in order to retrieve the roaming number of the initiating party. 3. The HLR responds with roaming number. 4. Nobill sends an InitialDP request to the PrePaid System (PPS), i.e. to the SCP. The request is sent over INAP/CAPv2. 5. The PPS detects that the initiating user does not have enough balance and sends a ReleaseCall request. 6. An USSD response is sent back to the initiating party displaying a message that the request was rejected.

Copyright Symsoft AB

Limited

Вам также может понравиться