Bridging the fiber network operations gap: sending out crews - part 1.

Welcome back to ByteSize Fiber, the podcast where we explore the real-world challenges and smart solutions shaping the future of fiber and telecom, one byte at a time. I'm your host, Ellie Pulse, and this is episode three in our Network Operations series. In today's episode, Sending Out Crews, part one, we're looking at the critical steps operators should take before a technician ever leaves the depot. From pre-job checks to planning for the unexpected, we'll break down what it takes to make every site visit count. As always, I'm joined by James Roach and Stefan Schneider, who bring a wealth of experience from both the field and the control room. Let's get started. In your guys' experience, what do you think some of the most important things that an operator should do before sending a crew to the job site? So, one of the things that we have to think about now is our networks are so complex, and there's so many different types of architecture. Before you're sending crews out, you need to know what they're dealing with, where they're going, especially if it's construction or even a big outage. Is it this architecture? Do you have the equipment on your truck? Can you look at where you're going and see real-time assets and go, hey, I'm missing this. Before I head out there, I better have one of these just in case. So, it's a lot of pre-planning, but it's having that ability to look at a real network, a true, real live network on a platform and go, hey, this was just changed. We keep seeing this problem. Maybe there's something else I need to look at. And having those records and anything that we can do to improve that. Because we used to send crews out to do things. Now it's one person. Yeah, we're in this minimal kind of one technician's going to do it all. So, they have to have as much information as possible so that they know what they're getting into. They can validate the equipment on their trucks. They can validate the tools that they need to troubleshoot it. Or they can communicate that, hey, I'm not the best person for this because I don't have X, Y, and Z. And so, they're not wasting time getting there and then realizing it's there. And you can think of it this way. Like, there is a drive for service providers to maintain operational costs down, make the networks more efficient. And that means that the crews that are on the field need to be more efficient in terms of, A, being able to quickly identify the root cause of a fault. Number two, making sure that they have, like James said, the right equipment, you know, not just the equipment to diagnose the fault in the truck, but also if they need to replace something, that they don't have to dispatch a new truck or that they need to go back to warehouse to pick up things. So, making sure that they have the right load. But then the third thing is, you know, network failures tend to be cascading events. Something goes wrong and usually where it goes wrong is not necessarily the first place that you actually felt it. Understanding where the assets are in the whole path of the network, you know, leading to where that, you know, specific event happened, it's useful to detect alongside other data, like network performance data. Is this actually the place where the problems happen? Because it's easy for things like a fiber break, right? You know that, you know where you're going to go and approximately start checking fiber to find the point where it broke. But if it's a much more complex logical service disruption, then you need to actually coordinate with people to go ahead and say, well, you know, we think that performance degraded from this port down, you know, go hunt where it's happening. It's a much more complex and less fun process. And anyone that's had the pleasure of doing wireless networks and trying to figure out if performance problems are at the radio or a back hole or somewhere else will tell you that sometimes you dispatch crews to try and find problems. And they basically are flying blind when it comes to what asset might be the one to blame. And how do you feel data about your network impacts this? The more data you have, right, the easier it is to understand based on the physical relationships of assets where the problem might be. But the key for that is that you actually have to put that data to work alongside the asset map. If you don't have them correlated and talking to each other, then you're missing out on a great opportunity to actually simplify the process that it takes to actually identify root causes or identify problematic areas in the network. Right. So the more data, the more you correlate it and the more you make it accessible makes a difference. There's no such thing as too much data, but there is such a thing as having too much data that you need to swivel between seven screens to check. And the more screens that you have to swivel, the less likely it is that you're going to swivel towards any other systems because it takes time and goes back to what we said before. You know, operators are under pressure to keep their costs under control. And that means being more efficient on the spot. James, do you have any examples in your experience where better network data kind of reduced downtime or helps to resolve something faster? So, yeah. And kind of to piggyback off what Stefan just said, when you look at data from a technician's point of view, it's great to have all these different inputs. But at the end of the day, it's about interpretation. So there's multiple times where we've been out in the field working, trying to identify a problem. And we're trying to identify all these different things coming in. Are the phone networks affected? Is it this frequency range? We used to operate in very low frequency ranges. Now we're up to there's some 1.8 gig forwards. You know, we're dealing with really complex systems. And I've had instances where we were able to start to correlate very specific frequency spectrums that were affected. So being able to pull modem health and say, hey, it's only modems in the return spectrum at this block of frequencies. So we could start to target that and identify that and troubleshoot it. That's something that even if we change processes and make things impactful, we have to display that information so it becomes useful. The technicians out in the field and it could be night, it could be raining, it could be snowing, it could be all these things. Because they've got to be able to look at that data and go, okay, I've got an idea of how to troubleshoot this now. Because nothing is making sense. Because yes, all the data in the world is great. You've still got to have someone in the field to interpret it. And so we've got to make that one of our key factors. And something moving forward is how do we display it so that it can be identified? So that if you're tracking a difficult issue, you can pinpoint what data stream is actually the most important for you to be looking at.