Prepaid Call Flow Algorithm

7/22/2019 Prepaid Call Flow Algorithm

1/15

Date: Feb 01, 2013

COMMUNICATIONBETWEEN

NETWORKING ELEMENTS

Prepared By: Vikash Tiwari (evikati/EGIL01634) IN-BO, SLA


2/15

Communication Between SSF & SCF: Voice Call FlowA. Consider the following diagram:

B. Explanation:1. Initial DP:This message contains service key (that shows subscriber has prepaid services), calling partynumber (MSISDN), Event type BCSM (collected info DP), called party number, location information, callreference number (VMSC address), MSC address.2. RRBE (Request Report BCSM Event):This indicates the triggers that need to be monitored in the MSC andto be notified to the SCF such as O_answer, O_disconnect, O_busy, O_abandon, O_select route failure, O_noanswer.3. Continue Message:It instructs SSF to continue the call processing after notifying the triggers that has beenencountered to SCF, without waiting for further instructions from SCF.4. Apply Charging:This message contains max call duration, release if duration exceeds, party to charge.5. ERB (Event Report BCSM Event):This message notifies the triggers encountered in the SSF like O_answer,

to the SCF.6. Activity Test:This message is sent periodically to the check if the connection is active.7. Apply Charging Report:This message is in response to the Apply Charging message.

SSF

Initial DP (OCSI)

RRBE (O_ANSWER, O_DISCONNECT, O_BUSY, O_ABANDON )

Continue, Appl C!a"#in#

ERB (O_ANSWER En$ounte"e%)

A$ti&it Te't (O_ACTIE)

A$ti&it te't_a$

ERB (O_DISCONNECT En$ounte"e%)

Appl C!a"#in# Repo"t

oi$e T"an'*i''ion

oi$e T"an'*i''ion

Relea'e Call

SCF


3/15

Communication Between SSF, SCF & SDP: Voice Call FlowA. Consider the following diagram:

SDPSSF SCF

1. Trigger IN service 2. 1stinterrogation, rate the call & check subscriber a/c

3. Result: call allowed, allowed duration, announceent

!. "la# call setu$ announceent

%. onnect to called subscriber ' re(uest )nswer *vent

+. alled $art# answer

. -onitor call or call events e.g. duration, release0

. )llowed duration reached

. Interediate interrogation, deduct one# & check a/c

1. Result: inal credit, allowed duration, announceents

12. "la# warning announceent or tone

11. -onitor or call events

13. )llowed duration reached

1%. 4inal interrogation

1+. 4inal interrogation result

1!. "la# end o call announceent

1. Release call1. 5enerate 6R


4/15

Originating CS1+ Flow:A. Consider the following diagram:

B. Explanation:1. Call is initiated by subscriber, OICK of the subscriber in the VLR, routes the call to the SSF.2. The SSF collects data about the call and triggers CCN.3. CCN performs a SDP selection and sends the data to SDP(first interrogation).4. SDP reserves money from the account and sends the calculated call time to CCN, together with other calldata such as announcements to be played.5. CCN tells the SSF to play announcements(insufficient balance), CCN tells the SSF to setup the call and tosupervise it based on the call time calculated by SDP(Reservation).6. The call lasts longer than the call time sent to the SSF, so a notification is sent to CCN.7. CCN requests SDP to make another reservation from the account with an intermediate interrogation.8. SDP makes a new charging analysis and deducts the amount previously reserved from the account.9. CCN passes the new call time on to the SSF (Step 69 can be repeated several times).10. The call lasts longer than the call time sent to the SSF and a notification is sent to CCN.11. CCN requests SDP to make another reservation (with an intermediate interrogation).12. SDP sends the calculated call time to CCN together with an indication that there is no money left on theaccount and that a call cutoff warning announcement is to be played.13. CCN uses the 30 seconds indication from SDP (time between call cutoff warning and call cutoff).14. The SSF notifies CCN that the time sent down in step 13 has expired.15. CCN sends the remaining 30 seconds and tells the SSF to play the call cutoff warning announcement.16. The SSF notifies CCN that the final 30 seconds has expired.17. CCN tells the SSF to play the call cutoff announcement and to disconnect the call.18. The SSF notifies CCN of the call disconnection.19. A final report is sent from CCN to SDP. SDP performs final charging of the call.20. SDP rates the total call and sends a final report result to CCN.21. CCN sends a call release to the SSF.


5/15

Interface Protocols Towards AIR:A. Consider the following diagram:

Refill Through IVR

UCIP

DNS

RPC

SIP


6/15

B. Consider the following diagram:

USSD Re+ill

C. Explanation:1. ISUP:It is an SS7 protocol that provides the signaling functions required to support basic bearer services. Itis used between MSC and HP-IVR or VXML-IVR.2. UCIP:It is an IP-based protocol used for integration towards the AIR server from the external application.

UCIP is an XML over HTTP based protocol, which makes it easy to integrate with a central integration pointwithin a network. It is intended for user self services such as: Account Refill, Adjustments, Account Enquiries.3. VSIP:It is an XML over HTTP based protocol, which makes it easy to integrate with a central integrationpoint within a network.4. RPC:This protocol is used both by MINSAT and ASCS for administration of account and subscriber data,and for user communication through SDP.

EAP

SIP DNS

-./RPC


7/15

Voucher Refill Through IVR:A. Consider the following diagram:

B. Explanation:1. A refill call is initiated by the Charging System Subscriber.2. The call is routed to the IVR. The IVR checks if the calling party number is complete.

3. The IVR requests account information from AIR.4. AIR interrogates AF to get the SDP IP address.5. AF returns the SDP IP-address.6. AIR uses the returned SDP IP address to request account and subscriber data information from SDP.7. SDP checks if any account updates are necessary and sends the result of the account information requestsback to AIR.8. AIR sends the requested information to the IVR, for example preferred language. The IVR plays a standardwelcome announcement and a menu announcement. The subscriber selects the menu option Voucher Refilland enters the voucher activation number.9. The entered activation code and the mobile number of the subscriber is sent to AIR for verification.10. AIR requests account information from SDP.11. SDP sends the result of the account information request back to AIR. AIR verifies that the subscriber exists

and is not barred from refill.12. AIR sends the entered voucher activation code to the Voucher Server (VS) for verification.13. When the VS has verified the voucher activation code and reserved the voucher, it returns a response toAIR.

A No Co*plete

Re0 A/C In+o"*ation

A/C 1 Su2 Data

.an#ua#e

o2ile 1 A$ti&ation Co%e

Su2 E3i't 1 Allo4 Fo" Re+ill

A/C In$"ea'e%

Un2a""e%

Se"&i$e'

Noti+ Su2'$"i2e"

(Re+ill Su$$e''+ul)

Su2 Rel Call

CDR

ISUP

UCIPDNS

RPC

VSIP


8/15

14. AIR receives a response from the VS indicating if the verification was successful or not. It was successful,so AIR sends a refill request to SDP.15. The account balance is increased in SDP database for the account.16. SDP sends the result of the refill back to AIR.17. The refill was successful, so AIR requests the VS to set the voucher in used state.18. The VS responds with the result back to AIR.19. AIR sends a response to the IVR including the account balance and an indication if the refill was

successful or not. A CDR including the refill data is generated.20. The IVR uses the voice prompt to notify the subscriber of the result.21. The subscriber releases the call.22. A CDR is sent to the Multi Mediation Solution as a receipt (optional).

Balance Enquiry Through IVR:A. Consider the following diagram:

B. Explanation:1. An enquiry call is initiated by the Charging System subscriber.

2. The call is routed to the IVR. The IVR checks if the calling party number is complete.3. The IVR requests account information from AIR.4. AIR interrogates AF to get the SDP IP address.

A Nu*2e" Co*plete

Re0ue't A/C In+o"*ation

A/C 1 Su2'$"i2e"

.an#ua#e 1 Balan$e En0ui"

Re0ue't A/C In+o"*ation

Pla Re' e''a#e

Su2'$"i2e" Relea'e


9/15

5. AF returns the SDP IP address.6. AIR uses the returned SDP IP address to request account and subscriber data information from SDP.7. SDP checks if any account updates are necessary and sends the result of the account information requestback to AIR.8. AIR sends the requested information to the IVR, for example preferred language. The IVR plays a standardwelcome announcement and a menu announcement. The subscriber selects the menu option Balance Enquiry.9. A balance enquiry request with the mobile number of the subscriber is sent to AIR.

10. AIR enquires SDP for account information.11. SDP sends the requested account information to AIR.12. AIR forwards the account information to the IVR.13. The IVR plays a response message.14. The subscriber releases the call.15. The MSC informs the IVR about the completion of the call.

Voucher Refill Through USSD:A. Consider the following diagram:

Se"&i$e Co%e 5 ou$!e" Co%e

A/C 1 Su2'$"i2e" Data

A$ti&ation $o%ee"i+ 1 Re'e"&e ou$!e"

Su$$e'' Re'ult

Balan$e In$"ea'e

Un2a""e%

ou$!e" U'e% Re+o"*ate Into USSD

Te3t St"in#

USSD Te3t St"in#

CDR

EAP


10/15

B. Explanation:1. A Charging System subscriber originates an USSD message with the USSD service code corresponding tovoucher refill and the voucher activation code.2. The MSC forwards the message to the HLR.3. The HLR analyses the USSD service code and forwards the message to AIR.4. AIR interrogates AF to get the SDP IP address.5. AF returns the SDP IP address.

6. AIR uses the returned SDP IP address to request account and subscriber data information from SDP.7. SDP checks if any account updates are necessary and sends the result of the account information requestback to AIR. AIR verifies that the subscriber exists and is not barred from refill.8. AIR sends the activation code to the VS for verification.9. When the VS has verified the activation code and reserved the voucher, it returns a response to AIR.10. AIR receives a response from the VS indicating if the verification was successful or not. It was successful,so AIR sends a refill request to SDP.11. The account balance is increased in the SDP database.12. SDP sends the result of the refill back to AIR.13. The refill was successful, so AIR requests the VS to set the voucher in used state.14. The VS responds with the result back to AIR.15. AIR reformats the response into a USSD text string and sends it to the HLR. The response is successful, sothe appropriate successful message is sent, otherwise a failure response with the reason for failure would havebeen sent. A CDR including the refill data is generated.16. The HLR forwards the response to the MSC and the response is displayed on the subscribers handset.17. A CDR is sent to the Multi Mediation Solution as a receipt (optional).


11/15

Balance Enquiry Through USSD:A. Consider the following diagram:

B. Explanation:1. A Charging System subscriber originates a USSD message with the USSD service code corresponding toenquiry.2. The MSC forwards the message to the HLR.3. The HLR analyses the USSD service code and forwards the message to AIR.

4. AIR interrogates AF to get the SDP IP address.5. AF returns the SDP IP address.6. AIR uses the returned SDP IP address to request account and subscriber data information from SDP.7. SDP sends the requested account information to AIR.8. AIR reformats the response into a USSD text string and send to the HLR. The response is successful, so theappropriate successful message is sent, otherwise a failure response with the reason for failure would havebeen sent.9. The HLR forwards the response to the MSC and the response is displayed on the subscribers handset.

USSD Se"&i$e Co%e

A$$ount In+o"*ation

Re+o"*ate Into USSD St"in#


12/15

MNP Prepaid Call Flow:A. Assume A and B both are Vodafone Delhi Subscribers in different MSC/MSS coverage area. Consider thefollowing diagram:

B. Explanation:1. Subscriber A (prepaid) calls to subscriber B.2. Since A is prepaid first query(IDP) has to go IN/SCP with "calling party number" Subscriber A MSISDN and"called party number" Subscriber B MSISDN. Here is change from normal prepaid call flow, in normal case IDPwould have gone straight to serving SCP but in case of MNP IDP will sent to MNP server.3. MNP server will check its database for B MSISDN and add LRN/RN according to operator to which Bsubscriber is registered, in above case it is Vodafone Delhi. After addition of LRN/RN IDP is forwarded to SCP.4. IDP received by SCP contains LRN/RN + B MSISDN in "called party number" field and "calling party field"contains AMSISDN. Charging is done on the basis of LRN/RN. Here LRN is of Vodafone Delhi so local call rates apply tothis call. In normal scenario Charging would have be done on the basis on B party MSISDN. In response toIDP SCP revert with Connect/Continue message to MSC which contains "called party number" as LRN+BMSISDN.5. MSC check called party number and removes LRN (as its own LRN) and forward SRI to MNP server.

Hereafter normal MNP call flow is followed.6. MNP server checks B MSISDN and forward SRI to HLR.7. HLR queries with MSC B and provide MSRN to MSC A.8. IAM is send out to MSC B with called number at B party MSRN. Thereafter normal terminating call flowtakes place.
http://1.bp.blogspot.com/_RfbeICvJ9u8/TOj9FbgllMI/AAAAAAAAADs/d4ybAQGxIHU/s1600/MNP%2Bprepaid%2BCall%2BFlow.JPG


13/15

GPRS Attach & PDP Context Activation:A. Consider the following diagram:

B. Explanation:1. The terminal initiates the attach procedure after power on. Themessage contains the previously used TMSI (Temporary MobileSubscriber Id). The mobile network identity, the location area

and routing area information is also included in the message.2. The SGSN (Serving GPRS Support Node) searches for TMSI in its database.3. No entry is found for the TMSI, so the SGSN uses the old location area information to identify the oldSGSN where this terminal was being served.


14/15

4. The old SGSN responds with the GPRS mobile's IMSI(International Mobile Subscriber Identity) to the SGSN.5. The SGSN asks the terminal to identify itself.6. The terminal responds back.7. The SGSN authenticates the GPRS mobile by sending a RAND value(a random value).8. The SIM applies secret GSM algorithms on the RAND and the

secret key Ki to obtain the session key Kc and SRES.9. The computed SRES value is passed to the SGSN.10. The SGSN then requests the identity of the GPRS mobile.11. GPRS mobile responds back with the identity.12. Verify that that GPRS mobile being used by the user is not astolen one. The IMEI (International Mobile Equipment Identity)obtained from the GPRS mobile is sent to the EquipmentIdentification Register (EIR).13. The EIR clears the subscriber and responds back to the SGSN with the status.14. The SGSN now informs the Home Location Register (HLR) about the new location of the GPRS mobile.15. The HLR informs the old SGSN that the GPRS mobile has movedto a new location.16. The old SGSN acknowledges back.17. The HLR updates the new SGSN with all the subscriber information.18. The SGSN responds back to the HLR.19. The HLR now responds back to the SGSN's "Update Location"message.20. The mobile had initiated a combined attach, so the SGSN also updates the location information at theMSC-VLR that will handle the voice calls.21. The MSC also initiates an update at the HLR. The sequence ofactions here is identical to that of the SGSN's HLR update.22. The MSC informs the SGSN that it has finished the location update.23. The SGSN responds back to the original GRPS combined attachrequest from the mobile.24. The GPRS mobile acknowledges the receipt of "Attach Accept".

25. The Attach Complete signals the completion of the attachprocedure. This is passed to the MSC-VLR as "TMSI ReallocationComplete".25. The GPRS mobile now initiates the PDP context activationprocedure to obtain the IP address for the device. The Access Point Name (APN) specified by the serviceprovider is passed as a parameter.26. The SGSN initiates a DNS query to find the GGSN (Global GPRS Support Node) corresponding to the APNspecified by the mobile.27. The DNS provides the GGSN IP address.28. The SGSN routes the PDP context activation request to the GGSNcorresponding to the APN.29. The GGSN authenticates the GPRS subscription at the RADIUS

server.30. The RADIUS server successfully authenticates the subscriber and replies back to the GGSN.31. The GGSN now requests a DHCP server for an dynamic IP addressfor the GPRS mobile.32. The DHCP server provides the IP address.33. The GGSN responds back to the SGSN, indicating completion ofthe PDP context activation procedure.34. The SGSN replies back to the GPRS mobile. This signals completion of the PDP context activation.


15/15

THANK YOU

Prepaid Call Flow Algorithm

Documents

Transcript of Prepaid Call Flow Algorithm