Problem: a client should be provided with an opportunity to use a service for 2 hours on weekdays and download 1 Gb of traffic within the allotted time. Access should be denied when time or traffic quota is exceeded. Block should be cancelled at 7:00 (a client's timezone), a client is in Yekaterinburg. When access is blocked, https://eltex-co.com should be available. Other HTTP/HTTPS requests should be redirected to "Access denied" page.
To solve the problem, PCRF scenarios should be used. A scenario is a sequence of services. Services used in a scenario should be finite and have a condition for transition to next step.
A condition may be:
In scenario settings, again reserved word is available. It means a user should go back to the beginning and continue getting a service. In this case, limits on specific steps are set again.
SoftWLC and BRAS are assumed to be configured and put into operation.
Software version: SoftWLC 1.13 |
To solve the problem, two lists should be created: welcome and white_list. Welcome list is used during client re-authorisation and created when the initial SoftWLC setting is done to work with BRAS.
Select PCRF settings → URL lists tab in the Admin Panel.
The list should contain the address of the portal
http://10.10.5.50:9000/eltex_portal/ |
The list should contain the address of the resource that will be available when access is blocked. For convenience, enter the address as a regular expression
^(https|http):\/\/eltex-co\.com\/ |
Select Services and tariffs → PCRF services in the Admin Panel
The service will be the 0th step of our scenario. Set Time's quota and Traffic's quota in accordance with the problem statement
ip access-list extended INTERNET rule 10 action permit enable exit exit |
The service will be the first step of our scenario. The service will block Internet access, all HTTP/HTTPS requests will be redirected to "Access denied" page, https://eltex-co.com/ will be accessible via HTTP/HTTPS.
ip access-list extended WELCOME rule 1 action permit match protocol tcp match destination-port 443 enable exit rule 2 action permit match protocol tcp match destination-port 8443 enable exit rule 3 action permit match protocol tcp match destination-port 80 enable exit rule 4 action permit match protocol tcp match destination-port 8080 enable exit rule 5 action permit match protocol tcp match destination-port 9000 enable exit exit |
Account interim interval — 300 seconds;
Add URL filter with Permit action and a welcome URL list. This filter is used to allow access to "Access denied" page.
Add URL filter with Permit action and a white_list URL list. This filter is used to allow access to https://eltex-co.com
In the additional menu set block cancellation time
Block reset takes into account a client's timezone that should be defined in EMS service domain settings. If a timezone is not defined in a client's domain, a bottom-up tree search will be conducted. If a timezone is not found in parent domains, block reset will take UTC ± 0:00. Timezone is set in EMS domain settings |
Select Services and tariffs → PCRF scenarios tab in the Admin Panel.
Add the created services to the scenario, the services will be displayed from the top down
At the zeroth step, a client gets the service with quota (limit2h1Gb). When quota is exceeded, the first step with the blocking service will be available. The service will be operating until the reset. After the reset, a client moves to the second step and switches back to the zeroth one.
Select Services and tariffs → Tariffs tab in the Admin Panel, change the filter to PCRF/BRAS
Add a new tariff and select a previously created limit scenario
When a tariff is created, it should be assigned to a client's portal. For L2, a portal is selected in PCRF settings → L2 subnets tab of the Admin Panel. For L3, a portal is selected in EMS (SSID Manager). |
CheckCronBrasVerticle update interval is set in bras.cron.update.interval block of PCRF configuration
"bras.cron.update.interval": { "interval" : 1, "unit": "hours" }, |
Default update interval is 1 hour, in order to increase the number of checks, change the parameter and restart PCRF. For example, to update every 1800 seconds:
"bras.cron.update.interval": { "interval" : 1800, "unit": "Seconds" }, |
A client passes the registration and gets a configured scenario. To see which step a client is at and which services does he have, Mongo can be used:
> use pcrf switched to db pcrf > db.scripts.find({"user_name" : "79139001234"}).pretty(); { "_id" : "5d0c9359cc4e0c72ceb395ff", "domain" : "Auto1_test.Sibir.OTT.root", "title" : "limit", "user_name" : "79139001234", "step" : 0 } > db.service.find({"user_name" : "79139001234"}).pretty(); { "_id" : "5d0c9359cc4e0c72ceb39600", "user_domain" : "Auto1_test.Sibir.OTT.root", "user_name" : "79139001234", "service_list" : { "limit2h1Gb" : { "service_domain" : "root", "quota_time" : NumberLong(7200), "quota_volume" : NumberLong(1073741824) }, "blocking" : { "service_domain" : "root", "quota_cron" : "06/24/2019 - 07:00:00 YEKT" } } } |
The client is at the first step of a scenario including 2 services: limit2h1Gb and blocking. Two ways are possible:
If a client's quota is exceeded, PCRF will send a CoA request (command=services-reauth) to BRAS and switch a client to the next step of the scenario. BRAS will request services from PCRF and get data on the new step. The step number in Mongo scripts collection will be changed; the quota for limit2h1Gb service will be set again.
|
At the scheduled time, PCRF will review data in the service collection. If a client is at the zeroth step, PCRF will reset quota to an initial state; if a client is at the first step, PCRF will switch him to the next step, as a reserved word is "again". PCRF debug logs may contain the following lines:
==> /var/log/eltex-pcrf/eltex-pcrf-service.log <== 2019-06-21T16:09:16,955 [vert.x-eventloop-thread-2] DEBUG CheckCronBrasVerticle ?.(line:). Current time 2019-06-21T09:09:16.955Z 2019-06-21T16:09:17,070 [vert.x-eventloop-thread-2] DEBUG CheckCronBrasVerticle ?.(line:). Imagine time 06/21/2019 - 14:09:00 +0500 2019-06-21T16:09:17,071 [vert.x-eventloop-thread-2] DEBUG CheckCronBrasVerticle ?.(line:). Value {"quota_cron":"06/21/2019 - 14:09:00 +0500","service_domain":"root"} 2019-06-21T16:09:17,071 [vert.x-eventloop-thread-2] DEBUG CheckCronBrasVerticle ?.(line:). service_name blocking, cronTime 2019-06-21T14:09+05:00, service_domain root 2019-06-21T16:09:17,071 [vert.x-eventloop-thread-2] DEBUG CheckCronBrasVerticle ?.(line:). Difference 16 2019-06-21T16:09:17,071 [vert.x-eventloop-thread-2] DEBUG CheckCronBrasVerticle ?.(line:). Start to cron BrasCron(userName=79139001234, userDomain=Auto1_test.Sibir.OTT.root, serviceName=blocking, date=2019-06-21T14:09+05:00[Asia/Yekaterinburg], serviceDomain=root) 2019-06-21T16:09:17,076 [vert.x-eventloop-thread-1] DEBUG ReinitAllSerPersExcCronStrg ?.(line:). Search sessions by name = '79139001234' AND domain = 'Auto1_test.Sibir.OTT.root' for all services: [] 2019-06-21T16:09:17,076 [vert.x-eventloop-thread-1] DEBUG ReinitAllSerPersExcCronStrg ?.(line:). Try to get tariff domain for service name=79139001234, domain=Auto1_test.Sibir.OTT.root. Reload from base 25, hashed 41997. 2019-06-21T16:09:17,084 [vert.x-eventloop-thread-2] DEBUG CheckCronBrasVerticle ?.(line:). Successfully all checked |
The step number in scripts collection has changed:
> db.scripts.find({"user_name" : "79139001234"}).pretty(); { "_id" : "5d0c9359cc4e0c72ceb395ff", "domain" : "Auto1_test.Sibir.OTT.root", "title" : "limit", "user_name" : "79139001234", "step" : 2 } |
When a client returns, updated services consistent with the problem stated will be available for him.
If there are two or more services with quota within a scenario, and a client has not reached the blocking service, he will remain at the current service with quota, i.e. he will not be switched to the zeroth step. Once a client is reconnected, a service will not be fully provided, as the work will start from the mid-way point.