“The basic technical protocols that have enabled the Internet to work in such a globally interconnected way are developed and shared openly by a community of engineers.”
When evaluating OSS tools, I often look closely at the boundary cases… in a literal sense.
OSS rarely operate in isolation. They gain power through interconnectivity, through cross-sharing and cross-referencing of information to provide insight. We know that integration via APIs (Application Programming Interfaces) can be challenging, expensive, time consuming, etc and can be an area that requires great attention when architecting interconnected solutions.
But what we often don’t pay as close attention to is how the tools and data models handle Points of Interconnect that exist between networks, customers, other carriers, management systems, etc.
Some examples include:
- In an inventory system, a link between Multiplexer A and Multiplexer B has a single circuit name (let’s call it A-B-0001). The inventory system knows it as a single point to point link from a physical port on MuxA to another physical port on MuxB. However, from the perspective of an outside plant management system, a transmit/receive fibre pair is required to deliver A-B-0001. Each fibre is a “circuit” according to the outside plant management system from a patch panel at site A to a patch panel at site B (plus patch-cords at each end from patch panel to Mux). Each fibre circuit may actually traverse multiple components (eg patch panels, splice joints, attenuators, amplifiers). This circuit-pair to single circuit mapping can be confusing to some integrated OSS (eg mapping inventory to GIS)
- In a transmission network that consists of network A and network B, where each is managed by a different vendor EMS, an end-to-end circuit may exist between a customer-facing port on network A through to a customer-facing port on network B. There are interconnect points between network A and B, which are effectively patch leads between adjacent devices. But each EMS only knows about the half-circuit within its network and most likely doesn’t know about the patch-leads or the half-circuit on the other network. The OSS needs to know about which half-circuits map to each other and which patch-leads complete the half-circuit pairings
- An OSS has a routing algorithm built-in that helps network planners to design new circuits through their network. When designing an end-to-end circuit between customer Location A and Location Z it gets to an intermediate node and has the choice between 3 links to route the next hop of the fixed circuit. One link is leased from another carrier, one is a satellite link and the other is a highly congested on-net fibre link. Does the OSS‘s auto-route selection tool have the smarts to allocate different weightings to different link types? Is the weighting based on costs (eg perhaps the leased link is most costly), latency (the satellite link adds time delays), congestion (eg perhaps you prefer to load up your competitor’s network link instead of your own if you are incurring fixed costs anyway)?
- Many carriers utilise leased links that effectively go off-net (ie can’t be managed) so down-time on the leased link has to be monitored via adjacent points on the network that are managed. The leased link details also should be recorded in some way in inventory systems even though they can’t be discovered via API. This may require manual entries similar to patch leads in examples listed above. Various attributes, such as provider details, contact details, service IDs, etc would also need to be stored against the leased link
- There are many more you’ll be able to think of, especially from the perspective of billing reconciliation at each point of interconnect between carriers
Can you think of some other great POSSI examples worth sharing with the readers?Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email