Solving a Circuit Continuity Issue

Context

Our new customer (African telecom Operator) was struggling trying to resolve a circuit continuity issue with one of its clients.

After several intervention attempts with their common RHS partner, the customer decided to call us in order to investigate further about.

Client informed that their side was correctly patched and tested, and the Datacenter team confirmed the same at their side for Meet Me Room paths.

Resolution

After 10 minutes tracing the fiber path, CWS-TELECOM engineer found that the issue was as simple as a missing patchcord between ODF (rear side) and customer equipment.

➔ 20 minutes later, the circuit was up and running.

After being asked why he never informed the customer about such miss, common RHS partner simply replied that he was not requested (4 Times, approx. 20H work time invoiced) to check “this part” of the circuit…

Conclusion

CWS-TELECOM encourages its engineers to go beyond a “simple request”, not limiting themselves to stick to a demand, as a single point is important: problem resolution and customer satisfaction.

Cisco router decommissioning

Context

A French Web Services Hosting company requested CWS-TELECOM to proceed with a Cisco Router decommissioning.

As per Customer, plan was to simply disconnect power from router and proceed removal, as this device was not carrying any traffic anymore, then to store it for a future back shipment.

Resolution

Our concurrents’ engineers most common procedure in such case:

Simply proceed “as requested”:

• Enter room and find equipment.
• Disconnect power and remaining fibers / cables.
• Proceed dismantling.
• Leave site with equipment.
• Inform customer once reaching base that operation is completed.

CWS-TELECOM actions that were fortunately applied instead:

• Engineer entered room and found equipment.
• He contacted customer to inform he was ready to proceed, but also that he noticed that a few fibers were connected to the router still, and that he could observe some ports were looking actives too, so he required written confirmation to proceed removal.
• After checking, Design team (on the phone with CWS-TELECOM engineer) understood that, a few hours before, their NOC Team processed a few circuits rerouting via this node, in order to fix an outage (another router got down).
• As RMA procedure wasn’t completed yet (Replacement Line card awaited), circuits were riding through still, but Design team wasn’t aware of such emergency change.
• CWS-TELECOM engineer then proposed to investigate if replacement Line Card was delivered already in order to try to proceed RMA closure, then router decommissioning, customer agreed, and luckily, it was the case.
• Once customer sent an email confirming that operation was requested to be modified (they informed with location of faulty node, card to be replaced, and patchings to be restored), engineer processed replacement and, once stability confirmed, patchings restorations.
• CWS-TELECOM engineer then processed device decommissioning, as planned originally, under monitoring of Customer on the phone.
• As device was online just before and an inventory has been retrieved, he checked and confirmed that all inventoried cards and optics were present.
• He then left site with equipment, and stored it at Customer’s warehouse, as requested.
• He sent a confirmation email to customer 15 minutes before leaving site.
• Once back at base: he sent a full activity report.

Conclusion

If “conventional” process would have been applied, customer would have been left at the end of the “operation” with:

• 4 X customers down (10G Ethernet each).
• 1 X “still faulty” router
• 1 X “hardly recoverable” router (considering procedures to raise a new request + respective information required to reinstall it).
• Still no idea that there was a breach into their processes, so they couldn’t improve them.

Instead, they were quite happy that CWS-TELECOM engineer offered them the opportunity to “kill two birds with one stone”, allowing them not only to save money, but also valuable time for circuit restorations.

Permanent power rectifier failures

Context

A North African Telecom Operator experiencing frequent loss of connectivity and Power Rectifier failures in their Power Feeding Equipment Shelter, and always for the same slot.

Due to a lack of availability, their common RHS provider was unable to reach site in time for another replacement, so they requested CWS-TELECOM to proceed instead.

Resolution

Once he reached site, CWS-TELECOM engineer processed a simple survey, which allowed him to inform customer that one of their three air conditioning units was also faulty.

Then, once proceeding replacement, he of course checked before inserting a new module that nothing could block insertion, doing this, he observed and understood that the whole issue was due to a Flat ribbon cable getting punctured by the rectifier module alignment tip.

Indeed, as this power module was located just below the Management Unit, and the ribbon was incorrectly installed, as it was too loose, it ran into the slot underneath, generating short circuits and malfunctions of the whole system.

Once understood by customer, the issue got fixed the day after, CWS-TELECOM came back at site with a replacement ribbon, and processed Rectifier Module replacement at the same time.

Conclusion

Even though they’re not called out specifically for it, CWS-TELECOM engineers are proceeding with common checks each time they reach a site, not only for customers, but also for their own safety.

Also, they’re frequently recalled about best practices in Telecoms and IT, such as ESD prevention, slots clearance, fiber cleaning… to avoid risks while working.

Solving a Connection issue

Context

A north African IP/MPLS services provider trying to achieve last mile for circuit delivery.

Despite their efforts, they were still unable to observe client signal coming from Meet Me Room.

As per customer, another RHS was on site at their client end.

Resolution

After reaching site, analysing fiber path, and confirming with customer that patching was correct until last handoff point, CWS-TELECOM engineer decided to contact other end RHS to try to understand where the issue could be located.

It turned out that Client wasn’t really used with this Datacenter Meet Me Room demarcations naming, and that he probably gave wrong information to their engineer.

CWS-TELECOM proposed to Customer to let the client raise an access for him into the client’s room, in order to help locate the correct ports.

Client agreed, and after 5 minutes checking, CWS-TELECOM engineer understood where cross connection was, he confirmed then using a Visual Fault Locator laser that continuity was fine.

Conclusion

CWS-TELECOM pays high attention to the fact that, even though their engineers work for a specific customer, it doesn’t mean they can’t help “other ends” achieve a common Goal, in this example, connectivity completion.

Indeed, Telecom is a so small world that each achievement benefits to multiple Companies.