Calix Activate Integration

Calix Activate Integration

Last year Calix released Activate under their compass suite. Activate was branded to be the next iteration of SDN for their AXOS enabled products. At first I was told that Activate was going to eventually take the role of what CMS currently does, but as it stands right now, is only used for managing E3 and E5 G.fast devices. Which is why I had to start using it.

Late last summer we got a shipment of about 20 E3-16F units. These units are designed to provide gigabit speed over twisted copper pairs within a limited distance.

I totally jacked this image from this site.¬†Anyway these units are suppose to be the best solution for MDU (multiple dwelling units) deployments as they can utilize the existing copper infrastructure (since all buildings have phone) and reduce build out cost for ISP’s. This idea is sound, but there are a lot of variables that will determine how fast of a connection can be provided. Obviously distance, quality of line, shielding, vectoring, frequencies, etc are all factors in determining throughput. It brings all of the complications of DSL into smaller environments! It has just as many potential variables that must be considered when implementing. ūüėõ

A big project at work has been getting these things ready for deployment. They have been sitting long enough and are beginning to gather dust. Not to mention, depreciate. So while I have been focusing on finishing my degree at college, the team has been getting fiber connectivity to the comm rooms of some apartment complexes. I have been attempting to get the FMS ready for activate integration, and some of its key parts upgraded. A basic module level list is below:

  1. Plant management needs to reflect ‘Access Systems’
  2. Drops needs to allow for non fiber drop types
  3. Customer records needs to allow data pulls and provisioning to Activate

 

Plant Management

So I started on the Plant Management. I created this object called AS or Access Systems. Access Systems are any kind of device that resides in the field or needs to be placed on the map. For example, and E3-16F needs to be connected to the fiber PON system, but isn’t a terminal, because it does not simply pass through connections. Let me sidetrack and vent about definitions and terms in the telecom industry. Some terms are loosely used, and often over generalized while others are quite rigid and must be used properly. Terminal is a term used somewhat loosely. I have seen it used in conjunction with pedestals, or other enclosures for any medium. I have had to set a more rigid definition for when it is used in the FMS. Terminals in the past for the FMS has always been the bridge between infrastructure and customer premise. Which means if drop cable connects to the infrastructure in a utility easement, it is connected to a terminal. Or if it on the side of a building, and has multiple customer drops going into it, it is a terminal. The weird thing about the E3-15F’s is that they do conform to our definition of a terminal, but they also do not. Sure they connect customer drops to their premises, but they are also fed with one line, and do not have a 1:1 connection ratio. It is 1:16, and on top of that it uses two different mediums, so how beneficial would it be to look at a map an see a T instead of something like AS. At least you could know it was some form of infrastructure and not a ped in a comm room (huh?). Plus they are not passive and require power. Defining them as something other than a terminal allow us to hold a lot more attributes. Let’s dive into the details of how I made this stupid thing work.
Access Systems were created to work in conjunction of other devices. Currently only Activate is used for the access systems, but It was designed and built where we could use coaxial or other systems in the future. This required me to create yet another module called devices, which will eventually hold all of our network nodes.

This list sync’s with Activate on an hourly basis, checking for name changes and IP addresses changes of units. This is important to ensure that records are not orphaned. So once an hour is a good time interval.

If someone were to click the details page of the device, they are presented with device diagnostics

The details page is designed to provide an overview of the unit to the user so that any problems can be quickly seen. Reboot and Force Synchronization buttons exist and port details can be expanded to show which service are provisioned on the port. Alarms are shown to highlight attention.

Lets dive into the structure of Activate. This took me a little while to reverse and understand but hopefully the following graphic will help others understand how all the parts of activate work together. Bear in mind that this may not be the exact way things are stored, but is the best I could do from only looking at the web interface and API.

Basically two independent pieces are created. The Node record and Subscriber record. In the FMS, it is essential that that customer be linked to the node record, regardless of system, so I ended up spending a bit of time trying to find the structure so I could query any part of activate and eventually get back to the subscriber.

Subscribers are linked to Service Configuration records, which define what type of service to deliver to a port. Data, Voice and Video are all options. Service Configuration records are linked to a service template, which can be built in the activate interface under services. Refer to the Calix Activate documentation on how to configure these.

Ports are linked to a Port Configuration record, which defines what port level settings are assigned to the port. in addition Service Configuration records also associate with a port, so this is where everything really links together. The image below shows where to find the template settings for ports and services

Pretty much anything else regarding the Activate structure can be found in the Calix documentation. Lets move on to drops and how this structure can integrate the two systems.

Drops

Earlier we defined drops as a bridge between customer premise and infrastructure. This is true. In the case of G.fast, it is the copper line from the Access System to the CPE. The drop starts at the demarcation box and ends when it is plugged into a network terminal. Now modification of this module took a lot of time, and I’ll spare you the details because a lot of it was revamping the old code ( a lot from the first version of the FMS and some from the previous system before the FMS). Types were defined, so copper or fiber could be specified, and depending on the type, the logical cable spanned from¬†the address to terminal or access system.

Within the FMS, we now have all the links set up. Customers are linked to drop via address. Drops are linked to access system by plant management record. And customers link to Activate through subscriber customId. Now we have all the pieces to be able to connect activate and work between the two systems!

Customer

Up until this point in time customer records only contained device links to equipment (inventory module). With G.fast, devices are no longer assigned to customer, but rather ports were configured with services. So a new table was created to assign both ports and customers to units.

Next, to add a port, a drop (completed) must exist that is connected to an access system. Looking at the image from the drop section, the access system and port do in fact match and can be added to the customer. By pressing the add button, a provisioning wizard shows up. There is an error message because I already had service provisioned for the unit.

Once service is provisioned, the network terminal can be plugged in and it should start working. In addition, 801F’s and 844E’s can be assigned to customers and provisioned remotely.

That pretty much wraps up this post. It has taken some time, and the official deployment of the G.fast units has not occurred just yet, but it should be coming soon, and we’ll see what I have made holds up. I am currently making the system more robust and implementing features here and there. Some issues with Activate connectivity to the units has been causing some frustrations, so we’ll see how this thing plays out in the long run.

Finally I want to drop a link to the Compass Activate PHP Class for anyone who wishes to tie into the thing. The repo is here. It is still under development, so little to no documentation exists yet (5/22/2017). As always if you have questions please feel free to email me at gbrewster@agoasite.com

Comments are closed.