Prepaid Call Flow Algorithm

       Date: Feb 01, 2013

       

      COMMUNICATION 

      BETWEEN 

       NETWORKING ELEMENTS

       

       Prepared By:

       Vikash Tiwari (evikati/EGIL01634)

       IN­BO, SLA

Communication Between SSF & SCF: Voice Call Flow

A. Consider the following diagram: B. Explanation:  1. Initial DP: This message contains service key (that shows subscriber has prepaid services), calling party  number (MSISDN),  Event type BCSM (collected info DP), called party number, location information, call  reference number (VMSC address), MSC address. 2. RRBE (Request Report BCSM Event): This indicates the triggers that need to be monitored in the MSC and  to be notified to the SCF such as O_answer, O_disconnect, O_busy, O_abandon, O_select route failure, O_no  answer. 3. Continue Message: It instructs SSF to continue the call processing after notifying the triggers that has been  encountered 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 (O–CSI)

RRBE (O_ANSWER, O_DISCONNECT, O_BUSY, O_ABANDON ) Continue, Apply Charging

ERB (O_ANSWER Encountered)

Activity Test (O_ACTIVE) Activity test_ack

ERB (O_DISCONNECT Encountered)

Apply Charging Report Voice Transmission

Voice Transmission

Release Call

Communication Between SSF, SCF & SDP: Voice Call Flow

A. Consider the following diagram:

SDP

SSF

SCF

1. Trigger IN service

2. 1st _{interrogation, rate the call & check subscriber a/c}

3. Result: call allowed, allowed duration, announcement 4. Play call setup announcement

5. Connect to called subscriber + request Answer Event

6. Called party answer

7. Monitor call for call events (e.g. duration, release) 8. Allowed duration reached

9. Intermediate interrogation, deduct money & check a/c 10. Result: final credit, allowed duration, announcements

12. Play warning announcement or tone 11. Monitor for call events

13. Allowed duration reached

15. Final interrogation 16. Final interrogation result 14. Play end of call announcement

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 call  data 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 to  supervise 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 6–9 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 the  account 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.

Interface Protocols Towards AIR:

A. Consider the following diagram:

Refill Through IVR

UCIP

DNS

RPC

VSIP

B. Consider the following diagram:

USSD Refill C. Explanation: 1. ISUP: It is an SS7 protocol that provides the signaling functions required to support basic bearer services. It  is 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 point  within 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 integration  point 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.

EMAP

VSIP _DNS

XML/RPC

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 requests  back to AIR. 8. AIR sends the requested information to the IVR, for example preferred language. The IVR plays a standard  welcome announcement and a menu announcement. The subscriber selects the menu option Voucher Refill  and 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 to  AIR. A No Complete

Req A/C Information

A/C & Sub Data

Language

Mobile & Activation Code

Sub Exist & Allow For Refill

A/C Increased

Unbarred Services

Notify Subscriber (Refill Successful) Sub Rel Call

CDR ISUP UCIP DNS RPC  VSIP

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 Number Complete

Request A/C Information

A/C & Subscriber

Language & Balance Enquiry

Request A/C Information

Play Res Message Subscriber Release

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 request  back to AIR. 8. AIR sends the requested information to the IVR, for example preferred language. The IVR plays a standard  welcome 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:

Service Code + Voucher Code

A/C & Subscriber Data

Activation code Verify & Reserve Voucher

Success Result Balance Increase

Unbarred

Voucher Used

Reformate Into USSD Text String

USSD Text String

CDR

B. Explanation: 1. A Charging System subscriber originates an USSD message with the USSD service code corresponding to  voucher 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 request  back 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, so  the appropriate successful message is sent, otherwise a failure response with the reason for failure would have  been 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 subscriber’s handset. 17. A CDR is sent to the Multi Mediation Solution as a receipt (optional).

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 to  enquiry. 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 the  appropriate successful message is sent, otherwise a failure response with the reason for failure would have  been sent. 9. The HLR forwards the response to the MSC and the response is displayed on the subscriber’s handset.

USSD Service Code

Account Information

MNP Prepaid Call Flow:

A. Assume A and B both are Vodafone Delhi Subscribers in different MSC/MSS coverage area. Consider the  following 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 IDP  would 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 B  subscriber 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 A MSISDN. Charging is done on the basis of LRN/RN. Here LRN is of Vodafone Delhi so local call rates apply to  this call. In normal scenario Charging would have be done on the basis on B party MSISDN. In response to  IDP SCP revert with Connect/Continue message to MSC which contains "called party number" as LRN+B  MSISDN. 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 flow  takes place.

GPRS Attach & PDP Context Activation:

A. Consider the following diagram: B. Explanation:  1. The terminal initiates the attach procedure after power on. The  message contains the previously used TMSI (Temporary Mobile  Subscriber 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 old  SGSN where this terminal was being served. 

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 a  stolen one. The IMEI (International Mobile Equipment Identity)  obtained from the GPRS mobile is sent to the Equipment  Identification 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 moved  to 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 the  MSC­VLR that will handle the voice calls.  21. The MSC also initiates an update at the HLR. The sequence of  actions 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 attach  request from the mobile.  24. The GPRS mobile acknowledges the receipt of "Attach Accept".  25. The Attach Complete signals the completion of the attach  procedure. This is passed to the MSC­VLR as "TMSI Reallocation  Complete".  25. The GPRS mobile now initiates the PDP context activation  procedure to obtain the IP address for the device. The Access Point Name (APN) specified by the service  provider is passed as a parameter.  26. The SGSN initiates a DNS query to find the GGSN (Global GPRS Support Node) corresponding to the APN  specified by the mobile.  27. The DNS provides the GGSN IP address.  28. The SGSN routes the PDP context activation request to the GGSN  corresponding 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 address  for the GPRS mobile.  32. The DHCP server provides the IP address.  33. The GGSN responds back to the SGSN, indicating completion of  the PDP context activation procedure.  34. The SGSN replies back to the GPRS mobile. This signals completion of the PDP context activation.