In addition to RADIUS and REST, subscriber data can be retrieved from a number of supported billing systems.
Billing integrations support only IPv4 addresses.
Aradial
Aradial uses RADIUS. See RADIUS Interface chapter.
Azotel
The BQN retrieves the customer bucket data and gets from it the speed limits to apply (uploadrate and downloadrate).
To activate Azotel, in the BQN GUI go to Configuration->RADIUS/REST/Billing->Billing Systems, select Azotel and enable the switch.
A user and password will also be needed for REST/JSON access to Azotel. That user/password must be created in the Azotel system with allowed access from the BQN IP address. See Azotel documentation here.
The BQN will use its management address for Azotel queries, but bear in mind that if the BQN reaches Azotel over the Internet, Azotel will see a public IP address and this is the one that will need authorization by the Azotel system.
In the BQN GUI, configure also the Azotel system IP address or server name and port number (443 by default).
Azotel customers in a status other than “current” will be blocked (they are regarded as lacking a valid subscription). You can change this behaviour to non-blocking disabling the switch Block Inactive/Not Paying Subscribers.
Policy rates are taken from customer’s bucket fields upload rate and download rate.
With subscriber group information enabled, and if the information is available in Azotel database, the nickname of the parent of the customer CPE (e.g. an AP) will be used as a subscriber group, prefixed with “L1-“. Also, the site name where the parent is located will be a subscriber group, with “L2-“ prefix. So there will be two levels: a first level made up of AP subscriber groups (L1) and a second one with sites (L2), that can contain one or more APs.
Gestfy
Gestfy uses BQN REST API. See REST API chapter.
ISPCube
ISPCube uses BQN REST API. See REST API chapter.
See here the configuration instructions on the ISPCube billing side (go to Bequant tab at the bottom of the page).
ISPSolution
ISPSolution uses BQN REST API. See REST API chapter.
Microwisp
Microwip uses RADIUS. See RADIUS Interface chapter.
Powercode
To activate Powercode in the BQN GUI, go to Configuration->RADIUS/REST/Billing->Billing Systems, select Powercode and enable the switch.
Provide the Powercode system IP address or server name and its SSH port number (22 by default).
The BQN server needs SSH access to the Powercode server using a Unix User/Password.
In the Powercode system, we shall require a MySQL user and password. If the MySQL user/password is different to the Unix user/password, that should be specified in MySQL Credentials in the BQN GUI. The MySQL user must have read access to the following tables of the Powercode MySQL database:
- Services
- InternetInfo
- Equipment
- Customer
- CustomerServices
- AddressRange
Powercode customers in a status other than “Active” will be blocked (they are regarded as lacking a valid subscription). You can change this behaviour to non-blocking disabling the switch Block Inactive/Not Paying Subscribers.
Policy rates are taken from customer service Internet Info (MaxIn, MaxOut, BurstIn, BurstOut and BurstBucktTime).
With subscriber group information enabled, and if the information is available in Powercode database, the LocationID of the equipment of the customer CPE will be used as a subscriber group, prefixed with “L1-“.
REST-API Powercode
Powercode billing restricts REST API to three requests per second. For that reason, the preferred integration is using the MySQL access described in the previous section. REST-API can be used when MySQL cannot be used and the number of subscribers is low (one thousand or less).
The BQN retrieves CPE equipment of a certain category (1 by default). For subscribers with that category of equipment, it will retrieve the rate limits of their Internet service (“internetInfo”).
To activate Powercode, go to Configuration->External Subscriber Data->Billing Systems , select Powercode enable the switch.
An API Key will also be needed. The API key must be created in the Powercode system, with allowed access from BQN IP address (the BQN will use its management address for Powercode queries).
Provide also the Powercode system IP address or server name and port number (444 by default).
If the CPE equipment category in the Powercode database is other than 1, change it. More than one category can be specified typing the category numbers separated by spaces (e.g. “10 11 12” for categories 10, 11 and 12).
No retrieval of subscriber group information possible, use the SQL-based option instead.
Sonar
Sonar v2 is supported (the one with GraphQL API).
The BQN retrieves the customer tariffs and the speed limits to apply.
To activate the Sonar integration, go to Configuration->RADIUS/REST/Billing ->Billing Systems in the BQN GUI, select Sonar and enable the switch.
An API key will be needed. They must be created in the Sonar system. See Sonar documentation for details here.
Finally, in the BQN GUI, configure the Sonar system IP address or server name and port number (443 by default) in Configuration->RADIUS/REST/Billing ->Billing Systems, with Sonar selected and enabled.
By default, Sonar customers with account_status->name field with a value other than “Active” will be blocked (they are regarded as lacking a valid subscription). You can add more status in addition to “Active”, so they are not blocked either (see previous example, where status Employee has been added). You can change BQN behavior to non-blocking regarding of account status by disabling the switch Block Inactive/Not Paying Subscribers.
The following fields in Sonar billing can be used as source of the subscriber ID:
- Customer-ID (account ID field in Sonar).
- Name (account name in Sonar).
The speed limits are taken from data service detail fields:
- download_speed_kilobits_per_second
- upload_speed_kilobits_per_second
By default, the name of the rate policy is created internally by the BQN. Alternatively, if it is enabled the switch Policy names from Sonar service names, the policies will be named using Sonar service name plus the service Id appended to it, in order to have a unique identifier (Sonar service names alone are not guaranteed to be unique).
With subscriber group information enabled, and if the information is available in Sonar database, a subscriber group, prefixed with “L1-“, will be created based on the description of the parent inventory item of the subscriber’s inventory item.
Splynx
The BQN retrieves the customer tariffs, the speed limits to apply and the burst rates, together with burst thresholds and burst duration.
To activate Splynx in the BQN GUI, go to Configuration->RADIUS/REST/Billing->Billing Systems, select Splynx and enable the switch.
An API key and secret will be needed. They must be created in the Splynx system with the following settings:
- Enable basic authorization for this key.
- Leave empty Allowed list for IPs or include the BQN IP address. The BQN will use its management address for Splynx queries but bear in mind that if the BQN reaches Splynx over the Internet, Splynx will see a public IP address and this is the one that will need authorization by the Splynx system.
- Add view permissions for database items Tariff plans ->Internet and Customers->Customers online.
The following screenshots show the API KEY and the access permits:
In the BQN GUI, configure also the Splynx system IP address or server name and port number (443 by default).
Splynx customers with “1” in their blocked field, will be blocked (they are regarded as lacking a valid subscription). You can change this behaviour to non-blocking disabling the switch Block Inactive/Not Paying Subscribers.
The rate policy speed limits are taken from the Internet tariff associate to the online customer:
- seed_download
- speed_upload
No retrieval of subscriber group information possible, as there is no standard field in the billing system with that information.
UISP
There is an open source plug-in available in github. Supported by the community (no official support). It uses BQN REST API.
Installation
Prerequisites
- BQN with packages linux-R3.0.13-2-20231130 orlater and bqn-R4.18.8 or later.
- BQN with REST API enabled (see https://www.bequant.com/docs/rest#rest-configuration).
- UISP with REST API enabled with access to bothNMS and CRM. A common API KEY for both types of access must be created.
Steps
- Go to code repository and get the code zip file (in repository home page, go to Code->Download ZIP).
- Unzip the code zip file. For example with unzip command:
This will create a subdirectory named uisp-main.
- Create a uisp directory in the BQN server root account:
Where <BQN-OAM-IP> is the management IP address of the BQN server.
- Edit the file sync-uisp-bqn.sh to set the parameters to your environment values. Example:
- Transfer the following files from the PC to the BQN server using scp:
- In the BQN, copy sync-uisp-bqn.sh to the crontab directory so it is executed every 5 minutes:
And that's all, the script will access the UISP every 5 minutes and update the BQN accordingly. You can check the script log in the BQN:
To see the policies and subscribers created in the BQN server, see the section "Check the REST API" in https://www.bequant.com/docs/rest#rest-configuration.
Updates
To update the synchronization script, do the following:
- Go to code repository and get the code zip file (in repository home page, go to Code->Download ZIP).
- Unzip the code zip file. For example with unzip command:
This will create a subdirectory named uisp-main.
- Transfer the following files from the PC to the BQN server using scp:
Where <BQN-OAM-IP> is the management IP address of the BQN server. NOTE that the sync-uisp-bqn.sh MUST NOT be updated.
Known limitations
- The first time it may take minutes to run. Following executions will send to BQN only client changes and will be quicker.
- If the synchronization fails, no retry is attempted until the next scheduled task.
Visp.net
The BQN retrieves the customer tariff and get from it the speed limits to apply and the burst rates, thresholds andduration.
To activate Visp, go to Configuration->RADIUS/REST/Billing ->Billing Systems, select Visp and enable the switch.
A valid client id and secret and user name and password must be provided to the BQN in order to request temporal API tokens. A client id is unique per Visp installation. A user is any of the valid user accounts in that client to access the system.
The provided IP address or server name will be used, along with the port (443 by default), to requests API tokens (https://<server>:<port>/token) and also to send API queries (https://<server>:<port>/graphql).
The following screen shows an example of Visp configuration:
Visp customers with a package status and service instance status other than ACTIVE, will be blocked. You can change this behaviour to non-blocking disabling the switch Block Inactive/Not PayingSubscribers.
With the switch Block Inactive/Not Paying Subscribers enabled, the BQN will block subscribers based on two possible criteria:
- Status of service instances and packages (the default). If neither of them are in “ACTIVE” state, the subscriber will be blocked.
- Status of the subscriber account. If this option is chosen, subscribers in states Suspended, Hibernated and Inactive will be blocked (status codes 8, 9 and 10, respectively).
The following fields in Visp billing can be used as source of the subscriber ID:
- Customer-ID
- First +Last name
- Username
Policy rates are taken from customer’s service instance up_speed and down_speed. The burst rates up_burst and down_burst are also obtained.
With subscriber group information enabled, the access point identifier associated to the CPE of the subscriber, with an “L1-“ prefix, will be the name of the subscriber group, if the information is available in the Visp database.
WISPControl
WISPControl uses RADIUS. See RADIUS Interface chapter.
Wisphub
Wisphub has developed an integration with BQN using BQN REST API. See Wisphub product documentation here.
Wispro
The BQN retrieves clients, contracts and plans to get the speed limits to apply.
To activate Visp, go to Configuration->RADIUS/REST/Billing->Billing Systems, select Wispro and enable the switch.
A valid API key mustbe provided. The API key must be generated in the Wispro system. See instructions here.
The provided IP address or server name will be used, along with the port (443 by default), to send API queries to Wispro (https://<server>:<port>/api/v1).
The following screen shows an example of Wispro configuration:
Only Wispro clients with contracts in disabled state will be blocked. You can change this behaviour to non-blocking disabling the switch Block Inactive/Not Paying Subscribers.
The following fields in Wispro billing can be used as sourceof the subscriber ID:
- SubscriberID (“public_id” in Wispro client).
- Name.
- MAC address.
- Login (“email” field in Wispro client).
Policy rates are taken from the plan of the client contract. The plan ceil_down_kbps and ceil_up_kbps parameters are used as speed limits.
If a Wispro client has more than one contract, each IP address will be assigned the speed limits of its contract. If an IP address is repeated in two client contracts (this is an inconsistency in the billing database that should not happen), the limits of the contact obtained the last will be selected.
With subscriber group information enabled, node names will be used as subscriber groups, i.e., a subscriber will be associated to a subscriber group after the node name of the contract, if that information is available in Wispro database.
General Billing Considerations
Subscriber ID source
The billing system can be the source of BQN subscriber IDs. The choices of ID sources depend on the billing system (see each billing section for details).
For billing systems integrated using REST API, the billing system is in full control of the subscriber ID, that can be explicity defined when creating or editing the subscriber.
Block Inactive / Not Paying Subscribers
By default, BQN will block non-paying subscribers. What is a non-paying subscriber depends on the billing system (see each specific billing section for details). To prevent BQN from blocking non-paying subscribers, disable the switch Block Inactive/Not Paying Subscribers.
For billing systems integrated using REST API, the billing system is in full control of the rate limit definition and it can block a subscriber by assigning it to a policy with 0 rate limit speed.
Rate Scaling Factor
By default, the BQN will apply the rate limits as specified by the billing system. It is possible to apply a scaling factor to those limits using the field Rate-Limit Scaling.
To enforce a speed limit lower than the one in the billing, use a factor less than 100%. For example, a limit in the billing of 200 Mbps with a factor of 90% will be 180 Mbps.
To enforce a speed higher than in the billing, use a factor bigger 100 % and up to 200% (maximum factor possible). For example, a rate of 200 Mbps in the billing with a factor of 150% will be 300 Mbps.
For billing systems integrated using REST API, the billing system is in full control of the rate limit definition and can decide which factor if any apply to the limits sent to the BQN.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.