APIO for Broadworks – integration made easy

APIO is a mediation layer between network elements such as the Cisco Broadworks platform and Northbound resources that include a customer self care portal, provisioning tools and general integration with IT systems. APIO is used as a replacement for Cisco’s now defunct Loki platform.

Netaxis’ approach with Broadworks has been to provide users with a maximum amount of self care facilities whilst limiting the required level of IT integration at the Service Provider.

Provisioning and integration with Northbound systems should be restricted to what is strictly necessary to bill customers. For example the number of users, the quantities of licenses consumed and phone numbers.

2 step provisioning approach

Service providers leveraging APIO typically implement a 2-step provisioning approach:

Step 1

Here the initial setup of the enterprise and/or group is done. This setup is limited to the creation of the basic skeleton and to the allocation of resources that the customer can use such as group services, numbers and end user service licenses/packs. This provisioning can be done:

• either manually via commPilot or via the APIO provisioning GUI
• or by integrating on the APIs of APIO (e.g. online signup, based on previously created quote, …)

Step 2

All detailed configuration: group creation, user creation, service pack assignment, feature configuration etc are handled through the self-care portal:

• Admins and end users will get a welcome mail once their profile has been created, inviting them to access the portal
• The portal is also accessible for service provider technicians and resellers. Such users have the same view as other (normal) users and admins but with the difference that they search and access more than 1 customer.

Figure 1 – advised way of working

Services & service packs

Although Broadworks provides a vast amount of end user telephony services not every user needs them all.  Building a good customer value proposal means providing customers with the right set of features.

Broadworks therefore allows the service provider to determine per tenant, per group and even per user which services can be used and which can’t. If not authorized and not assigned, the user or group cannot use that feature. The selfcare portal and the underlying API take this principle into account and won’t allow nor show such features when not assigned.

Due to the large number of potential services, individual assignment of services is a hassle. Broadworks supports the notion of service packs. A service pack is typically a bundle of user services which you can give a name of your choice:

e.g. BASIC_SERVICE, PREMIUM_SERVICES, VOICE_MAIL

Service packs can be authorized and limited both on tenant as well as on group level. As long as service packs are available to a group, the group admin is able to assign service packs to a user. When such a service pack is assigned to a user, all services constituting that package are assigned to the user and become available for the user to consume.

Of course, the Broadworks platform is a licensed platform. The main licensing is done based on users and group services provisioned on the platform. The more advanced the features you assign to a user, the more expensive the Broadworks user license. For example a business line license allows you to assign call forwarding and other basic services to a user while the premium enterprise package additionally provides advanced features such as time based forwarding and flexible seating. Typically service providers create service packs which are aligned with the licensing scheme of Broadworks. There is no general rule for this but it usually looks like:

• A service pack containing basic services like call forwarding, call waiting
• A service pack containing premium services like time based call forwarding
• A service pack containing a voicemail user service
• etc

Most of the time, service providers charge their customers a monthly fee which is proportional to the volume of service packs consumed by that customer. In that context, both the API as well as the portals facilitate the limitation of the number of service packs, services and group services an enterprise or group can consume.

In principle there is no limitation on how you build your product model nor is it mandatory to leverage these service packs. However to leverage the out-of-the-box experience to its full extent service pack usage is advised. Due to the vast amount of end user services the design choice was made to:

• not expose service assignment directly in the selfcare portal
• map “service packs” to “end user licenses”
  • note that the terminology “licenses” does not refer to Cisco Broadworks licenses but to billable resources that your customers are allowed to use.

This means that in the case where individual services (e.g. “voice messaging user” for the Broadworks voicemail) are assigned based on the customer order it is advised to have them defined in separate service packs.

Figure 2 – “License” view as seen from within the provisioning portal

Device management

The Broadworks platform offers a comprehensive device management solution that simplifies the integration, deployment, and maintenance of access devices such as IP phones, IADs and ATAs in the service provider’s network. For this purpose the Broadworks Profile Server (PS) and an XSP application container for device management are leveraged:

• Broadworks facilitates
  • specification of device configuration templates per type of access device
  • creation of devices and their association with users
• once the latter happens a device configuration file will be automatically created and populated with configuration parameters specific to the user profile(s) associated with the device (e.g. SIP credentials) based on the provisioned template
• the template is made available for download through the XSP application which is or should be exposed on the internet.

The Netaxis APIO platform further enhances this solution with:

• Secure zero touch configuration
• Visual device management

Through the self-care portal it is possible for a support engineer as well as a customer administrator to assign a device to the user profile in question. 

In line with the general philosophy of the platform, it is advised to leave device management assignment in the hands of your customers instead of trying to do this from within the OSS/BSS layers.

For a full zero-touch experience, following Broadworks device assignment APIO updates the redirect servers of supported phone vendors. This forces the phones upon boot from factory defaults to redirect to the device management servers of your Broadworks deployment for up to date device configuration.  All the service provider needs to do is ship devices/phones to the customer. The customer easily links the shipped devices to the correct account and immediately start using the service. Once linked to the platform, APIO and the selfcare portal are able to provide visual device management capabilities.

Figure 3 – Netaxis integration for device management

So that’s it. Broadworks integration made easy. Read this previous blog post if you want to read about how Netaxis use APIO as a Loki replacement . There is an older blog post about Loki replacement strategy. Other stuff about APIO is on our product page. Feel free to contact us if you want to talk about your own Broadworks provisioning and customer self care portal requirements.

Written in conjunction with our very own and very excellent Bart Coelmont.