Latest from Home
Talent, Tools, and Templates, to the Rescue —
Virtually every network operator would love to migrate their old, legacy network toward new, state-of-the art infrastructure, even without being driven by 5G technology introduction. This is not surprising, as there are many good business reasons to migrate legacy networks: cost reduction, improvement in quality of service and customer experience, footprint reduction, power savings, and advances in technology, are just a few.
The fact is that growing, or even just maintaining, outdated technology is not effective, because:
• Older equipment and solutions are not scalable.
• Older equipment is often at end-of-life and/or end-of-service.
• There is limited availability of experts for legacy platforms.
• Older equipment consumes too much space.
• Older equipment lacks open APIs and common data models.
• Managing a network with a wide mix of technologies, vendor platforms, and generations of equipment, is inefficient.
InvisiLight® Solution for Deploying Fiber
April 2, 2022
Go to Market Faster. Speed up Network Deployment
April 2, 2022
Episode 10: Fiber Optic Closure Specs Explained…
April 1, 2022
Food for Thought from Our 2022 ICT Visionaries
April 1, 2022Despite these compelling business drivers, network migration programs often stall. There are significant obstacles hindering the decision to migrate a network and associated network services. It is a complex and error-prone process that is not well supported by tools typically in use, and therefore involves considerable manual work. Furthermore, there is often a disconnect between actual network data and expected network data, a result of a network that has grown naturally over many years with little to no attention to clean-up.
There also may be ramifications from company mergers and the resulting variety of operations support systems (OSSs) and processes. This overwhelming complexity, which spans a multitude of technologies and equipment managed by vendor-specific network management systems (NMSs), effectively blocks network-wide data synchronization and adds to migration risk. Service providers with large networks get frustrated by these barriers and are seeking ways to overcome the challenges that inhibit network modernization.
Traditional Network Migration
Traditional migration is the tried and tested process to migrate networks from older to newer technology.
Figure 1. Traditional migration process.
As depicted in Figure 1, this process is initiated by the service provider.
• The network elements to be migrated areselected, and this information is provided as a list to the selected migration partner, typically the original equipment manufacturer (OEM) for the new technology.
• The migration partner will then assess the parameters and feasibility of the migration by verifying the network status in the diverse NMS systems or even in built-as-use (BAU) documents.
• Assuming a positive outcome of the feasibility study, the next steps will then be detailed in per-site planning, which is followed by the generation of the respective work orders and procedures and finally the execution of the migration.
• Handmade tools are often used to speed up data collection or automate parts of the migration process.
This process is proven and still works in countless migrations or office exits.
Unfortunately, there are some limits to this approach. Consider the situation of complex legacy time-division multiplexing (TDM) networks with decades of history:
• The network itself is not homogenous and includes different generations of multi-vendor equipment that is irregularly distributed.
• Network data is distributed over multiple NMSs and OSSs, which have not been synchronized.
• Circuits in the network have not been properly activated or deactivated, adding to the inconsistency of network information.
• Knowledge about set-up and planning is scarce as the experts are no longer available, having retired or moved on to other roles.
The consequences of these conditions dramatically affect the traditional migration process.
• Traffic demand provided by the service provider to the migration partner might not be fulfilled because the assessment often proves that the data was wrong, and the migration is not possible.
• The migration process itself gets less and less scalable since a lot of effort is wasted in data verification and checks and updates in various legacy systems.
• And the end-to-end quality of the process is low due to unforeseen issues. This can result in end-
customer escalations and missed migration targets.
To add to these limitations, the lack of end-to-end visibility of the network severely handicaps the ability to complete a thorough business analysis of migration scenarios.
Effective business analysis allows migration projects to be constructed to achieve specific outcomes. These are typically:
1. Risk Reduction
a. Remove end-of-life (EoL) equipment
b. Enhance services performance by adding
resiliency and protection
2. End-Customer Considerations
a. Modernize their services (e.g., switch to IP-based services)
b. Improve service by moving circuits off deteriorating EoL equipment
3. OpEx/CapEx Reduction
a. Maximize reduction in space and power
b. Speed up planning processes and associated costs
Improving the Network Migration Process
A better solution would improve the migration process to cope with the complexities of network transformation.
SDN technology is an approach to network management that enables dynamic, programmatically efficient network configuration in order to improve network performance and monitoring, making it more like cloud computing than traditional network management.1
The intelligent integration of SDN orchestrator software into an enhanced migration process could evolve the traditional migration process. It would logically include 3 steps:
Step 1. Discovery andVisualization
Capturing all network information in a unified way from various sources (e.g., OSS, NMS, BSS) and collect this data in one common database to be used throughout the migration process.
Step 2. Analysis, Optimization, and Planning
Analyzing the network to remove inconsistencies in the various source systems, clean up incorrectly assigned or unused resources, and evaluate scenarios for migration. This step concludes with the preparation of a migration plan on a per-circuit level.
Step 3. Migration Execution
Applying workflow automation to the per-circuit planning to accelerate migration execution, including data clean-up.
Figure 2. Orchestrated network migration example of a real deployment.
It should be noted that for such orchestrated migration, the orchestrator itself would be used as a service tool. That means, it does not necessarily need to be integrated into the service provider’s IT environment. If not integrated, it can simply be removed when the migration is finalized. Figure 2 is an example of one such tool: Infinera’s Orchestrated Network Migration solution.
Capturing the Future
Having the ability to capture network information based on a unified network model from various sources, and to provide one common database of information, is the first step toward an automated and successful migration. This single database is then used for various visualization and grouping functions to provide one source of truth for migration planning. Automation tools are then leveraged to create a repeatable and scalable step-by-step process for the migration task itself.
Large operators with a wide array of network element types and vintages will especially benefit from such an orchestrated automated migration approach. The benefits include:
• Faster, more accurate, and successful, migration directly correlates to a reduction in manpower.
• Moving services to newer platforms and removing older network elements creates a reduction in footprint and power, with a corresponding reduction in associated expenses.
• Reducing the type and complexity of network elements in the network also correlates to savings in maintenance and support.
In the hands of an experienced service provider organization, orchestrated network migration can become a valuable use case for SDN technology.
Like this Article?
Subscribe to ISE magazine and start receiving your FREE monthly copy today!
Resources
1. Benzekki, Kamal; El Fergougui, Abdeslam; Elbelrhiti Elalaoui, Abdelbaki (2016). "Software-defined networking (SDN): A survey". Security and Communication Networks. 9 (18): 5803–5833.
Fisher, Sharon (1989). "OS/2 EE to Get 3270 Interface Early". Google Books.
This article is co-authored by Christian Uremovic and Ludwig Löebbecke
