2. INTRODUCTION
This project aims to establish the customer business requirements for “VAS
Based Consent Gateway at SE” .
Value Added Services (VAS) are mainly non core services beyond standard
voice calls and fax transmissions.
The Scope of this project is to introduce AOC (Approval Of Charge)
functionality in the Subscription Engine.
Approval Of Charge (AOC) functionality implies that for any VAS service to be
activated , the Content Partner has to take Approval for Charging from the
subscriber and then only activate that service.
This project intends to extend the scope for SE from maintaining just only
lifecycle of VAS Subscriptions to also maintaining the Approval Of Charge
functionality.
3. SCOPE
The Business scope of this project is that it will create a Consent Management
System which is a centralized repository for storing the customer’s consent for
the subscription based VAS services and it will generate a unique CG Id for
every transaction.
Also, CMS should be able to support the content partners integrated with SE
and offer the consent functionality for their subscribers on Unstructured
Services Supplementary Data Channel.
4. OBJECTIVES
The Business Objective of this project is to provide a centralized solution to
capture customer’s consent which would also enable the regulatory
compliance.
Through a centralized repository system, the consent of the subscribers on VAS
Services offered by different content providers will be stored at one centralized
location which will prove to improve the services offered to the general public
avoiding clashes and confusion.
5. CONVETIONAL PROCESS FLOW
In the present scenario , individual content providers have the ownership to
take the consent from subscribers before sending the VAS activation request to
the subscription engine.
Subscription Engine assumes that AOC has been taken successfully and only
manages the lifecycle of VAS Subscriptions.
6. VAS SUBSCRIPTION FLOW
The Content Provider will first receive consent from the customer for activation of
any VAS service.
Upon receiving the first consent from the customer , content provider will patch/pass
on the request to the CCG (Centralized Consent Gateway) for second consent.
After receiving the second consent from the customer , CCG will generate unique
CG id and redirect the transaction back to content provider which will pass it for
charging / provisioning / content delivery etc.
However , CCG will store each incoming request / logs for audit purposes with all
the details (i.e.) unique id , MSISDN details , service name , mode of activation ,
date and time stamp etc.
Subscription Engine will send a notification to CP whenever any charging approval
has been got .
Then CP maps this with acknowledgement received based on transaction id. Also ,
separate service document will be prepared by SE and send to CPs to handle new
statuses related to AOC requests.
8. CUSTOMER CONTENT
PROVIDER
If Reply
is “NO”
AOC
Consent
needs to
be
triggered
from SE
AOC
Consent
need not
be
triggered
from SE
ENDSUBSCRIPTION
ENGINE
To Confirm
your
Subscription
Request ,
Reply “1”
USSD
AOC
Message
VAS Activation
Request
Reply
Reply
??
Replyis“1”
within
Timeout
SUBSCRIPTION
ENGINE
Confirmation
Message
CONTENT
PROVIDER
Contd.
in the
next
slide
9. Reply
????
If Reply is anything
other than “1”
Subscription
Engine
Customer
If
Timeout
has not
happened
If Timeout
has
happened
AOC Message
Content
Provider
Notifying CP
With timed
Out Response
Reply is
“1” within
Timeout
10. CUSTOMER BUSINESS REQUIREMENTS
1) Product Creation :-Two fields which are used for managing AOC Functionality are:
AOC Required : This attribute identifies whether AOC Consent is required or not whose
values can be either True or False.
True will imply AOC needs to be triggered from SE.
False will imply that AOC Consent is not required to be triggered from SE.
AOC Message :Whenever we have to take any AOC consent , then AOC message text is sent
to the subscriber by SE on the USSD channel with only static text which will be :
“To confirm your subscription request Reply 1” .
No other dynamic text will be added in this message including VAS name and also the
characters of the text must be limited to 90 while we are posting AOC message on the product
catalogue GUI otherwise an error message will be displayed.
11. CONTD.
The Error Message will be :
“AOC Message is greater than 90”
Important Points :
AOC message is applicable for parent products only which includes
Hello Tunes etc.
Suppose we have some child service associated with hello tune like astro
alert , then AOC consent will not be taken separately for it incase it is
activated.
After activation , a static and non - configurable confirmation message
by content provider will be send to the subscriber.
12. CBR CONTD.
2) New Activation Flow with AOC (on USSD Channel)
On New Activation, there can be two scenarios :
If we get a positive response for VAS for a new activation , then we need to take
the Approval Of Charge (AOC). For that , SE will respond back to CP with
acknowledgement message. Then, SE will send the AOC request to get
subscriber consent on the USSD Channel.
If the new activator is not interested in subscribing for any VAS service , then no
AOC consent will be triggered from SE end.
13. CONTD.
Multiple Requests for a Subscriber
If SE receives multiple requests for the same subscriber from CP , then SE
will send all those requests to USSD system and USSD will send the latest
request to the subscriber.
14. CONTD.
NOTE :
There can be a scenario when AOC message was posted but confirmation was not
received in the timeout period which is a pre defined interval for getting responses ,
then those request will not be stored as timeout at SE end.
Responses for an AOC Request
Successful Response
If we get a consent from the subscriber within the timeout period , then that request
will be processed for charging and so , will be considered as a successful response.
Timed Out
If Subscriber response is not received within the timeout period then that request
will be updated with timeout response and CP will be notified.
15. CONTD.
The AOC requests can be sent through a method known as the Circle Wise USSD
Instance described below :
First of all , SE will identify that which hub URL the subscriber belongs to from the
Network Directory Service.
Then SE will use that particular URL to post the AOC message to that subscriber
through the USSD system.
NOTE :
When SE receives a subscriber response , it sends an offline notification to CP and
CP maps this with acknowledge received based on the transaction id. This technique
is called Offline Notification to CP.
16. CBR CONTD.
3) Handling Subscriber Response
There will be a predefined response value treated as success in SE and sample AOC
Message Text will be :
“Get in touch with your culture in MKR. To confirm your subscription request
Reply 1.”
Now there can be two types of responses :
Success Response
If the subscriber replies with the value ‘1’ then it will be considered as a successful
response and SE will send a USSD message for confirmation from the subscriber.
This value ‘1’ is static and non-configurable for all products.
Invalid Response
If the subscriber replies with a value other than ‘1’ , then it is considered as an
invalid response. Suppose if user keeps on giving the invalid responses , then SE
will keep on sending the USSD message until the timeout period.
17. CBR CONTD.
4) Handling of Failure Scenarios
There can be multiple failure scenarios as mentioned below :
SE fails to post request to USSD system
If this happens then SE will notify CP with AOC failed response and CP needs to
resend New – Activation request for such records.
USSD fails to send subscriber’s response to SE
In this case , the response will be considered timed out at SE end and SE will notify
CP with timed out response.
USSD sends subscriber’s response to SE after Timed Out
As it is quite obvious that time out value at SE end will be higher than the time out
value in USSD system so the following condition is impossible to occur but if any
such condition occurs , then those requests will be stored as timed out at SE.
18. CBR CONTD.
5) Transaction Dump Changes During Reporting
AOC Failed
If the request for AOC fails due to any reason mentioned previously, then the
transaction status will be updated as :
“AOC Response : AOC Posting Failed”
Request Send For AOC
All those requests for which AOC request was initiated but no response has been
received yet , then the transaction status will be updated as :
“Request Send For AOC”
19. CONTD.
AOC Success
For all the activated requests , the transaction status will be updated as :
“Success”.
Time Out
Of all those requests for which the response was received after the timeout period ,
their transaction status will be updated as :
“AOC Response : TOT”
20. Assumptions
Applicable for both Bharti Prepaid and Postpaid Customers.
AOC requirement applicable for Non-HT Products on SE Default Platform only.
Timeout value at SE > Timeout value at USSD end.
Consent Confirmation and Invalid response messages will be same for all the
services having only static text.
SE will use XML over HTTPS approach to connect to USSD system.
Volumetric for USSD will be the same as New Activation Count in SE.
SE North and South will have different AOC instance and databases.
SE will not retry the requests which have failed while posting them at USSD
Channel.
No option in USSD text to capture failure from the customer.
The AOC Text Message by CPs will be sent through USSD channel only by SE.
CPs must adhere to 90 letter AOC Text Message limit.
21. CONTD.
For AOC based activation requests , charging will be an a sync transaction and CPs
will comply for the changes required for the same.
The Details of the consent ( confirmation date , time and AOC message ) needs to be
properly stored and is not strictly applicable for New Activation Requests.
SE needs to just pass on the requests to USSD received from CP irrespective of its
no. or kind but USSD needs check for multiple requests and send the latest to the
customer.
22. ABBREVIATIONS USED
CMS – Consent Management System
AOC – Approval Of Charge
VAS – Value Added Services
SE – Subscription Engine
NDS – Network Directory Service
USSD – Unstructured Systems Supplementary Data
23. Inference
The Consent Management System for VAS services at SE was developed
successfully.
