FiOS: Introducing Ethernet to the UMC

 

I have hinted at a couple of the issues that we ran into GPON already. Tellabs had cancelled the GPON development and then we had problems getting proper silicon from Broadlight. Now we come to a topic that will seem like a win, then become a challenge. We added Ethernet connectivity from the UMC to Juniper routers in the Central Office.

There was a slow, ongoing effort left over from the IOC IPTV developments that was looking into this capability for the UMC. The proposal was based 2 Wintegra Network Processors and a new ASIC for the UMC. The existing UMC backplane had several busses including a 2.4 Gbps downstream and 1.25 Gbps upstream buss. Part of the problem was that the silicon to use these capabilities and the software to drive them was in a prototype stage. The silicon had been demonstrated in 2003, but no progress had been made well into 2005.

Carl DeWilde came to the Engineering Team with an urgent requirement to put Ethernet CO connectivity into production ASAP. However, the schedule was challenged and contained a LOT of risk. We held several sessions with Carl and it was decided to do significant risk mitigation on the project. First, we would pursue 2 separate designs. The first was described above and was capable of providing 2 Gbps of capability. The second was a single Network Processor design and was designed to provide 1 Gbps of throughput. The CPU software (which drove all the internal connectivity) would limit the design to 622 Mbps throughput by only utilizing part of the busses available to the design.

Now we went with 2 hardware designs because the preferred design was so dense. UMC cards are about 5″ x 10″ and to make all the parts fit we had to go to a 22 layer printed circuit board. Given that the chassis limited us to 0.062″ board thickness we had to go into exotic materials. Our plan was to pursue this primary design and consider the other a backup. If we concluded that the primary design could be made to work, then we would cancel the backup design.

The software involved was also extensive for both the card development and system. Prior to this card, the Juniper routers were the Ethernet to ATM interworking point. Now this interface moved inside the UMC. You may not remember, but BPON was based around the exchange of ATM cells. The Technology Folks at Verizon wanted us to implement a very complex and complete provisioning model. We asked many questions about this as the ATM only model was simple (1 VCC per customer). The implementation of all this complexity is why we decided to stick with the existing throughput models. We knew we would be able to upgrade the software later to get to full throughput.

I want to point out something here for all involved in New Product Development. What happened was that we were able to describe the risks involved in the development very early on to the Executives. We presented various options to make the design more or less functional and risky. We participated in the discussions to choose a path forward and then reported progress against the plans. This joint planning and decision making meant that Engineering did not make all the decisions. It also meant that the Executive Team (in particular Carl) had a stake in our development along side of us. My experience has been that most Product Groups don’t like to present challenges and options until it is too late for the Executives to have an impact on the outcome. Once that is true, the Engineers (especially Engineering Management) own the outcome.  

I know the Product Groups don’t want to reveal the schedule challenges and risks.  They feel that they need to present a solution that meets all the requests without any issues.  Many of them have felt that presenting the issues will put their career at risk.  What those folks have found is that once things go off track that they own the problems.  The Executive Team hears about these problems first when they are reported as delays.  These surprises get folks fired.  What people should expect is Executives that push them to excel and stretch.  Highlighting risk points and potential issues early help Executives assess risks.

Now it turned out that the primary design worked and we were able to provide it to Verizon. And that is the next step in this story for tomorrow!

Jim Sackman
FocalPoint Business Coaching
http://www.jimsackman.focalpointcoaching.com/
We Focus On Your Business – Time, Team, Money, Exit
Business Coaching, Sales Training, Web Marketing, Behavioral Assessments, Financial Analysis
Lunch and Learn Tickets!

 

One thought on “FiOS: Introducing Ethernet to the UMC

  1. Venkatesh says:

    Ahh! Those were tough days. Thank you for your (and Shawn’s) invaluable guidance during that time. I learnt a lot of lessons and I consider those to be my very first lessons in dealing with projects and team members. I might have learnt many other lessons since that time but there will always be only one “first lesson”.

Leave a comment