Академический Документы
Профессиональный Документы
Культура Документы
APOLLO
Error! Unknown document property name. / SD
Apollo
Barring
Version 1.0
10 Assumptions................................................................................33
This section describes the current implementation of the Barring. Barrings are defined with CRM as products
and options and they are added to the Subscription / Account through the Order Capture / Service
Management.
Barring is of two type namely, Operated Assisted Barring and Operator Determined Barring.
Barrings can be done at both Subscription and Account levels. In case of Account level Barring / Unbarring,
the selected Barring / Unbarring is applied to all the underlying subscriptions. Barrings done at Account Level
can only be Unbarred at Account level.
Barring Options are configured as different Barring Products in the CRM system & Barring / Unbarring has
been defined as Actions within CRM. The different Barring Products defined in the CRM system are listed
below:
In case of the Operator Assisted barring, only a single generic product BOA is configured in the CRM
system.
Note: The capabilities for Operator Assisted barring types are also configured as products.
Capability
5. O2O0048 BOAAOC Barring Operator Assisted All Outgoing Calls
Capability
6. O2O0066 BOAIICC Barring Operator Assisted Incoming
International Calls Capability
All the related screens are under Setup CRM Common Definitions o2-Specific
Under Incoming Product Group, the Products Bar All Incoming Calls, Bar Incoming Roaming Calls are
included.
Under Outgoing Barring Type, the Products Bar All Outgoing Calls, Bar Outgoing Roaming Calls are
included.
All the other Operator Determined Barring Products are grouped under OTHERS.
Described in the next Figure, each Barring Product would need to be attached to the Barring Group.
Figure 1
Figure 3
In the following page, the Privilege for each and every User Group for access to the specific Barring /
Unbarring product are set.
1. A user group that has placed a barring request for a particular barring type is not allowed to place a
barring request for the same barring type (either at Account level or at Subscription level) again if the
earlier request is either Active or Barring-Pending.
2. In the case, if a barring type is either Active or Barring-Pending in the CRM system and another user
gives a Barring Request for the same barring type then No request is sent to EAI. The details will be
recorded in the CRM system with status as Active or Barring-Pending depending of the status of the
earlier request.
3. The Barring Request would be sent to the Network from CRM only for the first instance of a Barring
product per Subscription / Account. If more than one User Places the same Barring on a single Account,
only the first instance would be communicated and the next instance would just be stored within CRM
(for controlling the Barring / Unbarring Rules) and not communicated to networks.
1. If a barring (e.g. BICROAM) is being applied to a subscription/account which already has a barring
(e.g. BAIC) of a type that contains the barring being applied, then the new barring request needs
only to be stored in CRM and not sent to the networks. When the superset barring (e.g. BAIC) is
removed then if the subset barring (e.g. BICROAM) is still applicable then this barring needs to be
sent to the networks.
2. If a barring (e.g. BAIC) is being applied to a subscription/account which already has a barring (e.g.
BICROAM) of a type that is a subset of the barring being applied, then the new barring request
needs to be to be stored in CRM and also sent to the networks. The old barring type information
also needs to be retained in the CRM system. When the superset barring (e.g. BAIC) is removed
then if the subset barring (e.g. BICROAM) is still applicable then this barring needs to be sent to the
networks.
The following matrix displays the mutual exclusions for outgoing calls:
The following matrix displays the mutual exclusions for incoming calls:
Barring Type / BAIC BICROAM Bar
Barring Type International
Roaming calls
BAIC Stored only in Stored only in Only
CRM CRM BAOCROAM is
sent to
networks. The
rest of the
information is
stored in CRM
BICROAM Stored in CRM Stored only in Stored in CRM
and also sent to CRM and also sent to
the networks. the networks.
Bar Stored in CRM Stored only in Stored only in
International and also sent to CRM CRM
Roaming calls the networks.
1. Only an User belonging to an User Group having priority equal to or greater than the priority of the
User Group that had placed a barring can un-bar that particular barring.
2. If the Account/Subscription has a single barring deployed by more than one user group, then the
Unbarring request would be sent to the network only if all of them are initiated in CRM for Unbarring.
Else, they would only remove the respective Barring in CRM.
The Account Level Barring / Unbarring is used for deploying the Barrings for all the Subscription that belong
to the account.
There are 4 status followed within CRM Namely Active, Inactive, Barring Pending, Unbarring Pending.
Figure 6
The Barring Start Date and Barring End Date displayed on the Barring tab page and will display the Start
Date and End Date of the latest successful barring type barred / unbarred on the account.
When a barring request is placed in the CRM system the barring status becomes Barring-Pending and the
current date will be stored as the Start Date for Barring . When the Order Status becomes Complete or
Partially Complete, interface will update the Barring Status to Active and the Barring Start Date as current
date (i.e. the date when the status is received from EAI) for all subscriptions for which the barring request is
Successful.
The Barring Start Date in the Account is also updated with the current date.
For all subscriptions for which the barring request has failed, interface will update the Barring Status to
Inactive and update the Barring Start Date and Barring End Date as current date.
In case the Order Status is Failed, the Barring Start Date in the Account table will not be updated.
Barring History
Figure 7
7.2 Barring
1. Only one order will be created for one Account level request with each OLI corresponding to one
subscription.
2. After receiving the response from EAI, interface will update the status in the individual Subscriptions.
3. When an account level barring becomes Active, the MCR flag will be set and will be made display only in
the Barring tab page for the user groups whose priority has the permission to set the MCR Flag.
4. If the user groups priority does not have the permission to set the MCR Flag, the MCR flag will be
unchecked and made display only.
7.3 Unbarring
1. In the Unbar Account page, only one entry will be displayed for every request (No subscription wise
entries) placed at Account level. All the barrings placed by this user group and those placed by the user
groups whose priority is less than or equal to the priority of the current user will be displayed for selection
for Unbarring.
2. If order status becomes Complete or Partially Complete, for all the subscriptions for which the status
received from EAI is Successful, the Barring End Date as the current date. Subscriptions, for which the
status received from EAI is not successful, the Status of the barring in CRM would still remain as active.
3. MCR Flag will be unchecked if no barring types, placed by user groups whose priority has the permission
to set the MCR Flag, are Active on that account.
4. When unbarring at Account level by a user group whose priority has the permission to set the MCR Flag,
a check is made for Active barring types at Account level which have been placed by user groups whose
priority has the permission to set the MCR Flag. If there are no other Active barring types, the MCR Flag
is unchecked.
8.1 Barring
1. Three service actions are available for handling barring and unbarring Subscriptions. For Operator
Determined Barring at subscription level, two service actions are available namely Bar Subscription and
Unbar Subscription. For Operator Assisted Barring at Subscription level, one service action is available
namely Bar / Unbar OAB.
Figure 11
3. Just as in the Account level Barring, Barring request of a single product would be sent to the network
only once, while multiple instances of a single Barring type request by different user groups would be
stored within CRM to enforce the Barring Rules. The barring status of such requests in the CRM system,
will be either Active or Barring-Pending depending on the status of the request returned by EAI.
8.2 Unbarring
1. Unbar Subscription page will be used for performing the Unbarring at Subscription level. It can be noted
that the barring deployed at the Subscription level only could be unbarred in this page (Service
Management).
2. The Page would display all the Operator Determined Barring (that follows the above rule) that are placed
either by the current user group and all the Barring placed by the User Groups which have priority lesser
than the current User Group.
3. When the order is created, the status is changed to Unbarring-Pending and the relevant Barring Product
is set to Inactive once the Unbarring request is successful in the network.
Figure 15
Figure 16
For implementing Barring Operator Assisted Barring / Unbarring, we have configured a generic product by
name BOA. Service action to be selected on the Maintain Service page is Bar / Unbar OAB. Using this
action, Barring as well as Unbarring could be raised on multiple Operator Assisted Barring. The Rules
governing the Operator Determined Barring do not apply to the Operator assisted Barring.
More than one BOA barring types can be selected for barring or unbarring.
One single order is generated for the service action with the selected barring types as options.
For each of the selected BOA barring type, interface sends the corresponding capability as option with
attribute status as 1. (For each of the Operator Assisted Barring, the corresponding Capability is also set to
Yes by default within CRM).
TSPRSIC includes Bar Entertainment Numbers, Bar Service Numbers, BOIC and Bar International Roaming
Calls.
When a TSPRSIC request is received from CACS, a check is made if any the four barring types are Active
for all the subscriptions under that account in PS_O2_BARRING_STAC table.
1. An order is created if any of the four barring types is not Active in CRM for any of the subscriptions under
that account. Four entries will be made in PS_O2_BARRING_STAC table for each of the 4 barring types.
2. If any of the 4 barring types are Active or Barring-Pending in CRM for any of the subscriptions, an entry
will be made in the PS_O2_BARRING_STAC table for that subscription but it will be not be sent to EAI.
Except in the case where a BOIC is earlier placed by CACS, an entry will not be made in
PS_O2_BARRING_STAC table for barring type BOIC.
3. In CRM, no distinction can be made between a CACS request for BOIC and a BOIC barring request
made through TSPRSIC. So if a BOIC request comes first which is successful and then a TSPRSIC,
then entry for BOIC will not be made in PS_O2_BARRING_STAC table. Now, if an unbarring request for
TSPRSIC is received (BOIC entry will be made in the PS_O2_BARRING_STAC table when it was
placed against a separate BOIC request} will be unbarred (provided BOIC placed by some other user
groups is not Active for any of the subscriptions). Later when an unbarring request for BOIC is received,
it will be rejected since it will be Inactive in CRM.
If unbarring request for BOIC is received before unbarring request for TSPRSIC, then BOIC will be unbarred
for all subscriptions (provided it is not active against another user group). Later when TSPRSIC unbarring
request is received, it will be processed for only 3 barring types (Entertainment, Service and International
Roaming). If all 3 can be unbarred, the status of the order will be Complete.
11 Assumptions
1. Each user can be attached to only one User Group.
3. CACS has also been configured as a role. CACS user group will be given permissions for the entire
barring operator determined barring types. Fraud, and High Spend (mentioned as Barring Source in
CRM-EAI Interface Specification Document V 2.09) are not configured as Roles in CRM.
4. A user group that has been given the permission for barring will, by default, have the permission for
unbarring.
5. Any users having a priority greater than that of CACS can do unbarring of CACS placed requests
through CRM.
6. When any of the Barring Operator Assisted barring / unbarring request is placed, the attribute status
of corresponding Capability will be sent as 1. For example, if a request for BOAORB is placed
through CRM, then the value of the attribute status of BOAORC will be sent as 1 to EAI.
7. The restrictions in Service Management for executing a service action will not be applicable for any
of the barring actions i.e. Bar Subscription, Unbar Subscription, Bar / Unbar Operator Assisted
Barring.
8. No validations for unbarring Operator Assisted Barring is done user can choose one action either
Barring or Unbarring and can choose more than one BOA barring types.
9. Orders created for Account level barring will not be visible through GUI since these orders have
been created from the backend using SQL statements.
10. Bar Password Change is added to the dropdown "Barring Types" in the Barring Operator Assisted
page. When this item is selected, a text box will be displayed which will allow the user to input the
password. Every time the user has to type in the new password. Old password will not be stored in
the CRM. Interface will pick up this Attribute (Bar Password Change) and populate an Option
"BarringPasswordChange" with the Attribute as "Password" and its value entered by the user and
send to EAI. Entry will be made in the Barring Stack table but no validations are done. This means,
any user can place this request any number of times irrespective of the previous requests.
11. We have given translate values as 1, 2, 3, 4, 5, 6 to the field O2_PRIORITY. The assumption is that
priority 1 is highest and 6 is lowest.
12. If a CACSBarReq for unbarring is received for a barring type before the barring is Successful in
CRM, the request will Fail. For example, if CACSBarReq consists of any barring code (say UBOIC)
before barring is successful by BOIC, the respective request will fail.
13. Barring request placed at account level can be unbarred only by an unbarring request at the account
level. Similarly, barring requests placed at subscription level can only be unbarred by an unbarring
request at subscription level.