Provisioning Customers & Devices in Sonar

Whether you’re a new Internet Service Provider or you’ve been serving customers for some time but want details about exactly what Sonar does for your connection type, this article should clarify the various methods Sonar offers of provisioning your clients & controlling their access to services.

Sonar offers integrations with various hardware manufacturers, support for multiple simultaneous connection methods, historical tracking, and automatic provisioning based on account status or activity.

Managing end-user IP Assignments

When assigning IP addresses in Sonar, there are three possible approaches you can explore. These methods can work independently for your whole network or be combined with the other methods on a per subnet basis within a single Sonar instance.

1. Assigning the IP Address in Sonar and having the IP push down to the customer device, with this approach the initial IP assignment occurs in Sonar where the IP address is assigned either manually, or by selecting an IP pool and letting Sonar find the next available address in that Pool. Once the selection is made, this approach will then utilize the DHCP Server, RADIUS Server or LTE Core to assign the IP Address, depending on where the client device is requesting from.

2. Using your DHCP Server or PPPoE Pool to assign an IP Address to the client device and have that server send the IP information to Sonar as a “Soft Assignment”, meaning assigned by server software.Using this approach, a DHCP server would use a script and collect the requests in the DHCP Batcher, available at Github. Address assignment would then occur by matching the requester MAC address with the client MAC Address in Sonar enabling Option 82 on select devices to soft assign IP Addresses to accounts where the router is customer owned without needing the manually update the MAC Address store on the customer account.Lastly, an IP Assignment can be made directly from a PPPoE Pool and have the IP Address handed off to the RADIUS server, which in turn will send the assignment to Sonar to post an IP Address to the account which contains the stored RADIUS Credentials.

3. Finally, in the event of IP Addresses which require static assignment, IP Addresses can be assigned directly to devices through Sonar’s IP Address Management interface. Additionally, the IPAM interface is used to configure monitoring and alerting for the devices against which the IPs are assigned.

Controlling Account Data Rates & Access through Services, Usage-Based Billing Policies, and Billing

Sonar’s approach to managing provisioning of customer devices using Services, Usage Based Billing, and account billing doesn’t occur directly within Sonar, but groups of accounts can be categorized and managed based on different account settings. You can create address lists or RADIUS Groups based on account services, account groups, account types, account status, billing status, delinquency status, and usage-based billing policies. To highlight how these parameters are used, refer to the below examples:

Example 1: You’ve created an address list called “Residential_Delinquent”. This Address List groups IPs assigned to any accounts of the “Residential” type where the account is also in ’Delinquent” status due to an unpaid invoice. You would then go into the Inline Device, RADIUS Server, or DPI device and configure a filter rule or RADIUS reply that will drop all traffic for the IPs contained in this list.

Example 2: An address list has been created named “Gold_Legacy”. This Address list will contain all users of the “Gold” service who are part of the “Legacy” account group in order to separate and keep them distinct from accounts containing the “Gold” service but who are not in the legacy service area. This specification would allow different provisioning rules to be set for portions of the network without requiring CSRs to memorize multiple services based on geographical area.
Example 3: You’ve built an address list named “Over_Policy_Limit” where all Usage Based Billing policy services get placed together. This allows the building of a single list and single filter rule to rate limit various services when customers go over their monthly bandwidth allotments and have not purchased additional usage.

This logic can be applied to Inline Devices, RADIUS Servers, LTE Cores, and DPI devices such as Procera or Saisei devices, Preseem appliances, and other device types not directly supported using webhooks and API calls. These different provisioning approaches to managing account provisioning can be mixed and matched through your network and configured per subnet.

Getting data usage from customer devices into Sonar

Data Usage can be gathered and brought into Sonar through several methods, each with their own set of requirements.

Devices that support Netflow can forward this data to Sonar as a target, DPI devices that track usage will automatically drive data to accounts once they’ve been added as an inline device, and Preseem devices will also forward data usage once enable on the Preseem side, and RADIUS accounting data can be brought in to Sonar at the time a session is terminated. Finally, there are several API endpoints that can be used to bring data usage into Sonar from any devices that track this usage but don’t support the methods mentioned above.

Similar to shaping and filtering covered in the last section, these approaches can be mixed and matched throughout your network based on subnet.

Check out this short video on provisioning customer accounts in Sonar.  watch it here