Network Manager Telecom
Bitesize Fiber: Network Manager Telecom 3.4
Network Manager Telecom 3.4 release new features.
Ellie Puls and Stefan Schneider presents the latest release of IQGeo’s fiber and coax network management platform, showcasing powerful new features designed to help telecom operators work smarter, move faster and reduce the complexity of managing large scale network rollouts.
View transcript
Welcome to ByteSize Fiber, the podcast where we break down fiber and telecom challenges one byte at a time. I'm your host, Ellie Pulse, and today's episode is a special edition focused on the brand new release of Network Manager Telecom 3.4. This latest version of IQGeo's fiber and coax network management platform introduces powerful new features to help telecom operators work so well. smarter, move faster, and reduce the complexity of managing large-scale network rollouts. Joining me is Stephan Schneider, Product Manager for Network Manager Telecom. We'll explore what's new in version 3.4, the customer pain points that inspired it, and how these updates support everything from planning and design to operations and service assurance. Let's dive in. So, Stephan, for listeners new to IQGeo, can you give us a quick overview of Network Manager Telecom, what it does, and who it's built for? Yes. Hi, Ellie. So, I'm Stephan. I am Product Manager for Network Manager Telecom, and I am delighted to tell folks about Network Manager Telecom and what you can do with it. Network Manager Telecom is our physical asset inventory and network management system for fiber, copper, and coax, which allows you to model what infrastructure and assets you have in the real world, place them on the map, and add all the network features that define how these assets connect to each other and represent networks for telecoms. It is a system that you can use for your system of records, meaning you use this to represent your built records and your S-built captures. You can use it to help you plan and design, and it interfaces with network planning tools, such as Comso Fiber. But we have also been adding features into Network Manager Telecom to help you make use of our system, post the build phase into more of an operational context to help you with documenting operational change, helping you identify your asset states, helping you integrate with systems in your OSS and BSS stack, so the information about your asset state is always current and useful. Another driver. We have been bringing this as a theme starting with Network Manager Telecom 3.3 with our metadata engine. And we extended this as a theme. And we extended this metadata engine to be able to support attributes on strands, and that allows customers to define any sorts of attributes, say, for example, wavelengths or states, and use those attributes to represent operational state a lot easier and without any need for customizations. And then last but not least, customers were expressing some interest in helping them with design optimization once they're in the low-level design stage. They expressed some interest in us having more robust workflows to make changes to network designs without the need for so many clicks. So let's talk about those logical circuits. Why is that a game changer for visualizing or managing services? It sounds like a small thing, but depending on who you talk inside the telco operator, their definition of circuit goes from the light or the signal that passes between two ports to, oh, no, this is the service that my customer is paying for. And it spans multiple cables, multiple fibers, multiple structures, and lots of things. So for them to be able to actually map that logical service that other tools like provisioning systems, billing, and customer care actually understand, because that's how they define their customer services, and give them that context of this is the physical infrastructure on the ground that is carrying or representing the services, it's a game changer for them, because it allows them to understand how they're delivering services to customers. It allows them to understand when there is a fault, what customers could be impacted or what could be the potential revenue impact of these disruptions. And it also gives them a sense when they're doing work, either preventative maintenance, a break-fix operation, or even a new install, of what things they can actually work with or stay away from when they're doing work in order to not impact important customer services. So it allows that information also to be managed automatically from other systems instead of having to manually create it by hand. Great. And it sounds like that'll save a lot of time for technician and office staff, too. Absolutely. It's the key driver for us to wrap all these changes around our new APIs so we can save customers time, money, and effort by having systems communicate with each other. Some other features I know we have are audit trail tracking so we can know who made changes and when. Can you tell us about how this helps teams in practice? Absolutely. So prior to this release, the only way that you could do auditing was by going into the database and looking for changes. We understood that that was not necessarily the right level of exposure for these things for customers to get that information quickly and rapidly. But by adding this audit trail where you know who created a feature and when that happened and who was the last person to update it and when did that happen. In case that you need to check on someone's work or say, for example, someone accidentally deleted something that they shouldn't have and you're trying to figure out what happened when. This helps you identify those events inside the system, those changes that you need to be aware of and react to them the right way. So, for example, you can use this to resolve conflicts. Someone made a change. You know who made the change. You know what change was made and you can go back and discuss with folks what was the change, what was it made and resolve a potential conflict. Or you can use it as a way to basically backtrack new additions or changes into the system. So you can actually make sure that you have accurate data if someone introduces an error by accident. And going back to the strand level attributes, what kinds of new things can customers do now that they couldn't do before? I love our metadata engine and not because I helped build it with the team, but it gives customers this unlimited potential to reference in a geospatial context. So reference on a feature like a cable or an equipment port that has location and it's geospatially referenced. All these attributes that normally sit in other systems in OSS and BSS that have no geospatial reference. So being able to mark on a strand what wavelength it's using, what is its status? Is it reserved? Is it in use? Oh, no, this strand is actually damaged. Being able to add customer specific information like service IDs that might come from other systems or even getting more creative. We've spoken to folks about mapping things like IP addresses and phone numbers to ports. So if you're distributing services and you want to keep track of which customer or what phone numbers receiving that service, you can add that as a port attribute and query for it either internally or externally. We start talking to customers about things that you can do with strand attributes and the sky's the limit. You can, for example, record the glass type on specific strands, record the link to an OTDR test and have that information available. Map information from operational systems that might give you light levels, power and other information. Even go all the way to the logical service mapping and map things like jitter delay or packet loss on a specific fiber. It gives you the ability to basically map all these attributes and all this information that sits in a variety of systems into your system of records. So you can actually reference that for future break-fix activities, preventative maintenance, or even design. Using that information to influence the designs that you do, i.e., for example, avoiding creating new connections in areas where you might have cables that have been identified as running slow services or critical services. So you can pretty much do anything that you want in terms of mapping operational state and customer state into assets like ports and strands. And even set alarms, right? If you're building out something and you see that the fiber you want to use is reserved, it can set an alarm for you? Yes, it can. So we will be adding in future releases more logic internally to set up things like, for example, you want to monitor capacity, use those attributes to identify capacity constraints. Like, hey, you cannot create a circuit path on a fiber that is marked as reserved. Or you cannot create a circuit path on a cable whose capacity is up to 80% and this will become 81%. So the future with these attributes and this metadata is super bright. We'll be introducing capacity planning, this capacity reporting in our next release. But you can also take information from external systems, right? So alerts and alarms can come from many ways, can come from our system to the users. But you can also map external alarms from operational systems onto those elements. So if you're trying to do the sign work or restoration work and you have a strand on a cable that has been marked alarm because the service is alarmed, right? You know to avoid it if you're trying to provision a service through the same strand. You can use that to go like, oh, no, no, no. I need to provision my service through something else. So like I said, the possibilities are endless. And because we allow these attributes to be basically user -definable and open-ended and they're accessible via API, the sky here is truly the limit. Great. These are some really cool changes. I can't wait to see what our customers think. Yeah, I'm super excited to see what customers can do with this and very excited about the future of the things that we can do with these changes in the future and some of the new features that we're planning next. One of the biggest usability changes is support for long-running tasks. Can you tell us about what kind of operations caused problems before and what's different now in the 3.4 release? Absolutely. So let's start by introducing what our long-running task framework is. So we've added the ability to set up tasks and processes within our systems as essentially pieces or agents that can run independently in the background without necessarily locking the user out of the UI. In the past, we had some functions inside the product like file imports and our design validation check that tended to happen in real time. And because they happen in real time, if you had very large files or very complex designs, they could take a long time to execute and validate. And they would basically freeze the UI for the user until the task was completed. This obviously presents a problem. It's great to tell customers jokingly that, hey, go make yourself a cup of coffee and go take a walk while this completes. But in reality, that can lead, especially with very, very large files, to unwanted frustrations. So what we've done is by using this functionality that allows you to turn those tasks into background agents, give you the ability to set up a task, have it execute, and then notify you when it's complete. So what this means is that if you're doing something complex like uploading a very large design, you know, as you're publishing it, we give you the ability to run this in the background. And that allows you to do other things without, A, having to check the system to see when it's completed, B, locking the UI so you can do other things on the map without losing control, and C, be notified when these things are done. So you don't have to devote your full attention to the screen while these things are operating. That's going to be really helpful. Another practical upgrade is the smarter structure movement. Why was moving a structure such a headache in previous versions, and how does this update fix it? You have to understand a little bit where we came from and what our customers were asking us to record and design. For a lot of customers, basically, their workflows did not include a lot of changes to things after a design was created. But as we've grown and our customer base has grown as well, we have found new workflows where customers, after they've done their high-level design and their low-level design, they begin construction. And then they find out that they go and do a survey and they find the structure that should be, say, in one location. It's a few meters away along the same route. The key problem with that is that the way that we allow those moves basically will create a lot of real-time recalculations that could potentially create cable loops and other undesirable effects. So this is very different from moving a structure from one side of the street to the other or move a structure away from a route. But when you're trying to move a structure that should be in one location, either forward or backwards, if you wanted to do it without all those complications and the potential for cable loops and things like that, you had to go in. You had to disconnect all the cables. You had to disconnect or suspend all the circuits. You had to make sure that all the connectivity was done and then move the structure and then deal with the fact that that route's going to get split at this new location and then rename things one by one and reconnect things one by one. And it's a pretty tedious process. A lot of manual work, but by adding this tool, we've simplified the process. You can just move the structure along the route and it will automatically suspend connectivity. It will allow you to rename the cables afterwards and it will attempt, for the most part, to reconnect everything automatically. You might need to do some manual renaming of things just to make sure that things are matching. But it reduces the time that it takes to move a structure along that route dramatically. Great. Thank you so much for sharing, Stefan. My pleasure. Thank you.



