In this joint webinar with IQGeo & VIAVI.

Hello everyone. We're going to start the webinar in just a minute. We'll give people a chance to join us. So if you'd be patient, just one minute, we'll get started. We're going to get started in just a few seconds. We'll give people a little bit more time to join the session. I can see people, I can see from my dashboard user interface, I can see people are joining us and we still have a number of people coming into the webinar. So let's just wait 30 seconds. And then we'll get started with the presentation. Still a few people joining us, but let's, should we go ahead and get started now? Welcome everyone to this webinar. Patrick, I think you've got, there we go. Welcome everyone to this webinar. You've joined the webinar entitled Strategies for Automated and Efficient Fiber Network Fault Management. It's a snappy title, but actually to be all kidding aside, this has been an extremely popular topic. We have people joining us from all over the world, quite a, quite a long list of people from different industries. So I'm sure we've touched a nerve on this topic and it's really great to be doing this joint webinar together with IQGO and VIAVI. Before I introduce our speakers, let me just do a little bit of housekeeping. My name is Steve Tongish and I'm the Chief Marketing Officer at IQGO and thank you again for joining us. Throughout the webinar, we'll be doing a couple poll questions just to keep you awake. So we'll be pausing and asking, asking your opinion on a few of the related topics. If you have other more general questions, there will be time at the end for those. And within the GoToWebinar user interface, there's a question box and you can enter your questions there and we'll be handling them at the end of the session. You'll also see in the user interface, there is a handout box. And in there, there are a couple of different product sheets from both VIAVI and IQGO on this topic. So if you want to download those, you can do that. If you're interested in having these slides after the session, put that request into the question box and then we'll follow up with you later to assist. And we will be recording this session and we'll be giving you a link to it afterwards. So if you want to share it with any of your colleagues for on-demand viewing, you can do that. And then at the very end, after the session is over, we'll be asking a few survey questions just to help us improve what we're doing. So we would appreciate it if you took a few minutes to fill out those three questions. So with that, let's get started. We have quite a number of people on the call today. So let me introduce our two speakers. Patrick Farage, who is a global product line manager from VIAVI and Stephan Schneider, who is one of our senior product managers at IQGO. Hello, gentlemen, and welcome. Thank you, Steve. Okay, the stage is yours. All right, perfect. Let's get this party started. All right, so thanks, everyone. I'm, like Steve said, I'm Stephan Schneider, I'm product manager for telecoms at IQGO. For those of you who don't know IQGO, we are a geospatial asset management software. So we fall into the gallery of GIS as well as network, you know, asset management. We have about 450 plus telecom and utility companies that we serve around the world, you know, from all sizes, from all geographies. And what we focus on is the concept of accelerating time to revenue for customers. So we manage planning, design, construction. You know, we help with mapping operations and help, you know, sell network resources using our software. So you know where your resources are, you can map them accordingly and, you know, manage them, you know, from, you know, planning to design to build to operate. So a little bit about the company, next slide. You know, we have over 150,000 users, you know, over 200 staff, lots of customers. And we're a global company, we have offices all across the world. Next slide. So what I want to talk to you about is when you have, you know, data about your network, you have, you know, capture network details in a network map, you have all your assets map. What do you do with this in terms of operationalizing? Right. There are some challenges to actually get your network assets operationalized. You know, first challenge is that you always have data that's coming from multiple locations. They might be coming from different sources with different data formats. And you have a lot of manual processes to integrate them and make sure that they're all, you know, consistent in order to be used. For a lot of customers, there's also the issue of office and field separation. Tools are used, you know, in headquarters are not necessarily the same tools that the field has access to. And in some cases, data might be partitioned between field and head office. Workflows between, you know, the head office and the field are too complex to have them in a single location. And it's challenging to manage the costs, you know, related to having that data available. And then you end up with disjointed physical and logical assets. You end up with multiple inventory systems, you know, scattered sources of truth. You have issues mapping your logical topology to your physical topology. And more importantly, for a lot of systems, it's really hard to expose those physical assets outside of the map. So how or what are the strategies for you to operationalize that map data? The idea is that if you have, you know, accurate network data that you have collected, built and, you know, tested in terms of your design data and your S-built data, you need to do a few things to make that data, you know, usable from a testing and an operations perspective. The first thing that you need to do is you need to make your asset data actionable. All right. So you need to be able to synchronize, you know, your network data, your physical topologies with other systems so you can actually, you know, access them from anywhere. So you need to be able to have this, you know, the same amount of data and the same map visible in the office as you do in the field. The second part that you need to do is have that data be part of your OSS and BSS stack. So it's not good enough to just have a map, a map that you can actually query from your OSS and BSS stack using TM Forum service APIs. It's much more powerful and gives you the ability to actually enrich things. You need to know your asset location, right? You need to know where things are. You need to have a certain degree of accuracy on what's in the field, what has been built, and you need to be able to, you know, understand those topologies so you can do, you know, downstream and upstream effects whenever you have a fault. And that's all great, but that needs to leave the GIS system. You need to be able to take that data and use it to enrich your OSS, you know, assets with that physical asset inventory. So you need to be able to interact with query your map, you need to be able to run traces on the map, and you need to be able to take that information and use it to, you know, enrich your tickets and, you know, the data you put into the field. So what are the three steps, right, to operationalize those physical assets, right? First thing that you have to do, just in summary, create a single unified network view, right? It's the most important thing is for you to have the right data accessible by the people who need to, you know, deal with faults and be on the field. You need to be able to integrate data from all the systems and make sure that they're consistent. And you need to be able to make sure that that data is also integratable with other systems via APIs. The second part of your strategy, you need to make this data model. You need to have the same assets and data accessible in the office or in the field and support it on all devices, you know, that you support today. You need seamless updates to physical inventory online or offline. So if things change as things change in the field, you need to be able to have those changes reflect both in the inventory and in the field. And you need to give the reveal teams accurate, you know, map and location information so they can, you know, view the actual faults that they're working on. And then the last part is you need to make this data actionable, right? You need to be able to share location and equipment information between different systems and make that visible to different people. You need to use that physical asset information to enrich your alarms and alerts. And you need to implement workflows to automate ticketing for crews. So, you know, we'll talk about this in the next section of the webinar. Whenever you have faults that have been detected automatically, you can generate the right ticket information. So you have less swivel chairs and less, you know, manual intervention between identifying the problem and giving folks the right information to fix it. Here we go. I warned you all about this. We're doing our first poll question. So you should on the dashboard see a poll question pop up. And it is, how often do you send operational crews with break fixed tickets to the wrong response location? Do you never do it? You're perfect. It happens occasionally. It happens quite often or it's happening for your teams all the time. So I think this is a topic that Patrick and Stefan are going to address a little bit later in the session. So if you could quickly vote, that would be fantastic. I'll just wait another couple seconds because I think there's still some votes coming in. And it's probably enough time. Everybody's probably had a chance to answer. So do we want to display the results? Okay, so probably not unexpected. Any comment Patrick or Stefan? What do you think? 58% say it happens occasionally. Yeah, I have to say that I would have expected that to be, you know, a little bit less than that. But that highlights the importance of, you know, having your physical assets and your other systems working together. You know, if you're occasionally sending a crew to the wrong address, even if it's like two doors down, you know, that is cost that you incur on that ticket or potentially, you know, any customer escalations because you didn't show up on time. So that showcases the importance of what we're talking about today. Great. Okay, let's flip back to the presentation and continue on. So absolutely, that's a good introduction to remote fiber test systems. Thank you everyone for joining. Again, I'm Patrick Farage from VIAVI Solution Global BLM. Stefan just talked about how to operationalize your assets. What he didn't mention, because that's, let's say, VIAVI's part of the global integration and game, is how to make sure your asset is healthy and your network health is maintained and all the time. So just to make an introduction about VIAVI solutions for those who might not have heard of VIAVI in details. We are a global company, available global with more than 500 customers as well. We are leaders in test and measurement, but not only, we are also leaders in wireless and avionics and security, sensing and authentication. Today, we're focusing on test and measurement, specifically with remote fiber test solution. But VIAVI is present in fiber, enterprise, cable and access, metro and transport, and also lab and production and manufacturing. An interesting observation here is recently we had a look at the total fiber kilometer tested and assured and protected by VIAVI solutions. And we found out that since over 25 years, we've been monitoring more than 8 million kilometers of fibers. That's 200 times around the world. Just a snapshot of history of VIAVI building on innovation going forward. We have a long history, about 100 years. Last year, we celebrated 100 years, starting with Wandel and Goldman in Germany. But with the acquisitions over time and joint ventures, we became JDSU, which is what most of the audience know us for, JDSU for a long time. And back in 2015, we rebranded into VIAVI. And since then, we've been moving in VIAVI, continuing on our tradition to add innovations to our portfolio. Back to fiber monitoring and centralized test systems. Initially, as I said, 25 years ago, fiber monitoring has been introduced to the world. VIAVI started in 1995, installing systems in France. However, from classic fiber monitoring, the centralized OTDR system has been evolving all the way to fiber construction. So basically, early in the system, set up your OTDR centralized and use it to certify your construction and assure that your build is done as planned. But also moving into fiber analytics, taking all those data from your construction, testing and monitoring. And with business intelligence, be able to look at fiber trends and be able to monetize your fiber network infrastructure. That's from the fiber side. However, we've been evolving the centralized test system to cover more information about your critical assets and to protect the critical assets. So fiber strain information have been added with different OTDRs. Fiber temperature, locate fires and environmental events. But also the latest addition to our portfolio is the DAS, distributed acoustic sensing. Basically, be able to use the fiber to detect approaching intrusions and interference on your critical infrastructure. Remote fiber test solution brings value across all your network deployment lifecycle. As I mentioned, we no longer just invest in centralized fiber test system to monitor and already build assets and already build infrastructure. But coming in early to do the construction certification after that service installation, move to monitoring and then manage your asset is important in the network integration processes. No matter where you are in the network, no matter in which application you are, whether you are certifying your point-to-point feeder or PON network, whether you are in mobile backhaul application or point-to-point business, backbone fiber, and most importantly, your dark fiber in the ground existing for years, centralized fiber test system help you monitor your network and make sure your network health is excellent at any point in time. What are the components of the remote fiber test system? Basically, you start with hardware, your physical hardware in the central office or in a cabinet, in a central cabinet from where your network is being built. You need an OTDR and a switch and a lid fiber module, a device to be able to enable lid fiber monitoring or construction. Then you have the software application, which is based on three different modules today. The build module, which is your beginning of the centralized fiber test system process. You use your OTDR easily to do remote field testing while you are building your network. So the installer in the field is building step-by-step your network, can use the OTDR remotely to be able to qualify and certify every step of the build. Then moving into the monitoring module, which is exactly enabling you to do automatic fault location, linking that to your GIS inventory and landmarks to be able to identify faults and locate faults and dispatch someone to fix errors instead of locate errors. And last but not least, your fiber analytic model that allows you to drive operational excellence. So with this data that you get from the simple OTDR measurements, you are able to monitor your build progress. You are able to manage your inventory, manage your KPIs, tracking, reporting. But most importantly, when you look over your measurement data over time, you are able to do trend analysis and be able to move into predictive maintenance. You look at your data over time and you see some degradation. You figure out this piece of your network need a little bit more attention and you can react before faults start happening. Now, all of those modules interact with each other. And today, at the end of the last part of the presentation, Stefan is going to tell you how the interaction with the IQG or planning and design tool gets you the most out of that planning and testing investment. What are the benefits and the improvements delivered by remote fiber test system? This is information that we collected globally from projects that we have been seeing. Basically, when you test your network while you're building it, you enable faster service rollout with reduced errors. The monitoring phase allows you to reduce the mean time to repair. So by knowing the location and having the exact location of your fiber break or fiber error, you are able to dispatch immediately to that location. Enabling reduced truck rolls and monthly reduced outages when you are able to look at the global view of your network and predict where your errors are going to happen. This is an investment that both planning and design and test system is an investment that is needed the moment you start planning your network deployment. We spoke about VIAVI 20, 30 years ago. We spoke about IQG also being in business with design and planning for a long time. But trust me, we are not the first ones to do that. The first ever design and monitoring system, interestingly, started 2000 years ago with a Roman design of information and transport highway. I was very astonished with the information I found about what the Romans did back then. They did mapping and documentation. They provided the detailed snapshot of the infrastructure that we still have access to today. They actually took security measures. They did. They did. They changed simply. I think they have one version of the Microsoft, empty Wa11 part burgerows account. Thank you. You're not going to give any longer line any Absolutely, and I'll just continue on. Okay, let's go. And we'll see if Patrick returns, then we'll get that back. Okay, can you see my screen? Very clearly. Okay, here we are. Okay, so let me pop through to where we were with Patrick's slides. And he was talking about the Romans and about their test and measurement, which I think was a great story. Yeah, so basically to continue the story, right? The Romans had a really good system for monitoring and managing assets when they build their roads. If you page through the animations, you will see that the Romans would go in and document their roads, and that would create a map. They would also go and, you know, set up security measures to monitor and maintain those items on the map. If the animation is not going through, you might want to skip this slide. There you go. And, you know, they would basically optimize their maintenance activities based on that documentation and information that they got from their, you know, security measures, their patrols and watchtowers. So on the next slide, talking about integration, right? The idea is that we want to talk, there's multiple use cases, but we want to start with two, you know, main use cases. One is three-room-on-demand tests from IQgeo when you're doing tests and turn up. And the second one is to record your full location GPS coordinates. Yeah, there's a couple of animations here, so we might want to page through them. There we go. All right. So if we talk about triggering on-demand tests from IQgeo on the next slide. Oh, we have a poll question. Oh, yeah, for the poll. My bad. Okay. So let's jump into our poll, because we were talking about integrations, and that's exactly what this question is about. So you probably should see the poll question appear on your screen now. So how mature is your integration with OSS data and your geospatial network asset model? Have you begun it, or is it quite mature? So if you could quickly answer that poll question, that would be great. And then we'll look at the results. Oh, I can see one of our attendees thinks that maybe the Romans had a cyber attack. That's why we had the problem with our slides there. That's a good call. Okay. So let's see the poll results then. Let's see what we've got. That's an interesting result. It's 52% of folks who have not begun planning this integration. And this kind of maps a little bit, you know, one to one with folks that sometimes we're sending folks to the wrong address. So, you know, when the Romans allow you to, you know, reconnect, it might be worthwhile to actually put this into the list of things, you know, to do. In the past, we've, you know, heard from customers that, you know, especially the larger the number of customers and incidents you have a day, the more costly it becomes to send someone to the wrong address. And, you know, the cost of integrating the solution, you know, obviously outweighs the continuous cost of, you know, mistruck roles and, you know, screwing up your scheduling. Great. Let's return back to our slides. Yeah. Let's go into what people came for. So talking about the integration with IQgeo for on-demand testing, right? IQgeo actually has a set of REST APIs, more like the team form standards for resource inventory, where you basically can query, update, create and delete resources on the map based on this API request. So the idea of this integration is you speak to the network management system via REST API as, you know, as routes are being populated into the network management system, right? Whenever we query BO and MSI, we can actually retrieve the new routes that have been put into production and, you know, light it up into the map. So when the test is actually done either, you know, on-demand or automatically, we can then add information in the map for things like total loss and total distance, right, which, you know, we can take as attributes from the test being performed by the NMS. And you will see how this is, you know, it's very interesting when we go into the next use case. So this allows you, right, to start with this. This allows you to keep a very accurate record of your S-bill in terms of distance, recorded loss and everything else, visualize it on a map with, you know, accurate geospatial coordinates, but then reference it in the future. And as it changes, you know, be able to reference the rate of change of your loss and other fiber parameters inside the map. So on the next, on to the next use case. Right. The important thing or why would you want to have these things, is you can now use, sorry, go back to the last one. You can now use that information to basically trigger a trace whenever there's a break fix and do two things, right? If you detect the break fix, you know the distance, you can send the distance into IQGL, request a trace. The trace is going to, you know, reply with GPS coordinates and other details, you know, such as the equipment that sits at the location. If your fault is in the splice closure, you'll see the closure and the fiber that's actually being spliced, the port and all that information. And you can then take that data, you know, pull it back into your NMS system and enhance that into your outbound, you know, alarm and ticketing. Right. So you can do this via email or via SNMP. So what this allows you to do is, on the next slide, give your crews, if they're receiving, for example, an email, an embedded link with the view of the map and the GPS coordinates that they can use to drive to the right location, open the map into their environment, into their phones or laptops and see, you know, the map view of the fault and get the list of, you know, devices that, you know, are at that location and the actual ports and fibers that, you know, might be alarmed. And as you can see, that is really powerful because you're no longer counting on people having a printout or having to give them a printout of the network infrastructure or, you know, making sure that whoever built your your network management systems, you know, put all the information in place for them to actually locate and find the not just the location of the fault, but the equipment that's related on the fault, you're now giving that embedded, you know, completely. And that gives your field tags the ability to resolve faults much faster and have much more accurate information when they go on and deal with a fault. All right. So as you can see, that's the URL. The URL opens the map, the map gives you the location and it gives you the alarm details. And, you know, along those alarm details can be location, equipment, et cetera. Onto the next slide. And that's, you know, in a nutshell, just, you know, a teaser of the things that you can do when you integrate, you know, your test and measurement systems with your GIS asset management systems. It gives your teams the ability to be more effective in fixing faults, be more accurate in getting to, you know, response to a solution. But there's much more use cases that you can, you know, manage, you know, as part of integrating, you know, both your GIS system and your test and measurement system. And with that, you know, I'll put it off for Q&A. Okay. Thanks very much, Stefan. And we do have some questions that have come in from the audience. So let's kind of look through these and prioritize. The first one is, do you have your OTTR testing integrated with other systems in the stack? I think it's a good question because it can be a very complicated environment, can't it, Stefan? Yeah, it can become complex. And in a case of a lot of systems, you know, a lot of systems don't have open APIs for integration. So we often find as we go into customers, you know, mobilizing and opening, you know, the map with open APIs becomes the first priority. Once you've done that, integrate, element systems becomes much easier and, you know, much more powerful, you know, to handle. Another one that we have is, does FTH support event-based OTTR triggers? All right, Patrick, you're back. Patrick, you're back. Apologize. I had to download the app on my phone. My computer has no internet completely stopped. I have no clue. I have. We suspected it was the Romans who did it. You managed to get that. That's good, at least. Yeah. Well, you might want to run an OTTR test and see if you have a fiber. Absolutely. Absolutely needed. Absolutely needed. We'll get the coordinates. Okay. So, Steve, if you can repeat the question for Patrick as well. The question was, does FTH support event-based OTTR triggers? Absolutely. Absolutely. So, if you look at the slides with the build module, when you have your point-to-point link or your feeder in a PON link, you can look at the smart fiber grid, select one link or multiple links while you are building or after you build your network, and you launch an OTTR test, and then the smart link mapper is the result that you get, which is an event-based icon view option, as well as you can get access to your OTTR trace with all the events on the trace. So, yes, definitely. The FTH, the fiber test heads, like a smart OTTR in the field, supports an event-based OTTR analysis and approach. Okay. Excellent. Another, can Network Manager Telecom show live where the fiber event is? I think you touched on that a little bit, Stefan, but maybe you want to elaborate. Yeah, absolutely. So, you know, based on the information that we receive from the test measurement system, right, we can run a trace. So, you can show live on the map the location of the trace, right? So, we can choose to respond, you know, to the OTTR request with either a trace back showing live, you know, the location of the fault on the map or, you know, show the structure view, which is basically coordinates and equipment. So, we can support both views. So, here, let's see. Next one, do all customers work on the same server with IQGO or per client that is assigned to their own server? So, this is sort of an architecture issue about a question about how the system works. Yeah. We basically deploy, you know, we're very careful about, you know, customer data confidentiality, right? So, most of our customers have their own deployments. We have a SaaS deployment as well. And our SaaS deployment actually guarantees database privacy for each customer. So, there's no shared, you know, data for privacy and security reasons. So, technically, each customer actually works out of their own database. We do have some shared data feeds, like, you know, our maps. You know, we have external layers that we can import that we can then redistribute to multiple servers. But, basically, each customer kind of, like, operates in their own instance that either they host or we host for them. Here's one for VIAVI, Patrick. Does VIAVI support GSM 4G, 5G SIM module or SIM fault to send on mobile phones or on mobile? No, not at the moment. So, if I understood correctly, there was the fault mentioned in the question. So, fault location currently is sent by email with a GIS link. I think Stefan managed to send that, to show that in one of the slides. When you are using the system in a build mode, in a build configuration, and using the mobile app to test your test points, every measurement taken from the field is geolocated. So, from a GPS coordinates and so on. So, that's the extent of being able to identify your test points. But then, in a monitoring mode, when the fault occurs, then either you send the fault location via APIs or with an email with a GIS link. I think this is another kind of mobile-related question, Stefan. Is there an app for IQ.GO? Perhaps that means a mobile-enabled capability. Is that? Yeah. So, IQ.GO has, you know, support both for mobile browsers as well as a, you know, whole, like, mobile app that works on iOS and Android. We usually tell people to use iPads when it comes to the mobile app. And the reason for that is usually maps can be pretty large and complex. But phone screen resolutions are supported as well. Cool. Can you geolocate faults after the splitter in the F2, F3 section? Yes, you can. If, you know, if you model the splitter inside the network, right, so that requires you to have modeled the path correctly. But if you did that, we basically locate the distance. So, if the fault is, you know, behind, you know, F2 or F3, we will locate it as much as it was, like, you know, close to CO. Oh, here's an interesting one, maybe for Patrick. In FTDX networks, events are sometimes very close, like ONTs, et cetera. How can this be traced for deviations using this solution as testing through splitters uses long pauses causing longer dead zones? Does that make sense? Makes sense, especially the, yeah, distances that are being very close, especially in multi-dwelling units, FTDX applications. Basically, after the splitters, especially in a cascaded split mode 1 by 32 or 1 by 1 by 64, the detection happens based on a reflection event, okay? So, you need a reflection that is higher than the splitter noise in order to see up to the end of your network or your link. This reflection peak is the one that is being detected. And with high-resolution OTDR, like the CHR module that the Yavi FTHs, FTH 7000 and 9000 have, you would be able to separate peaks, so evented zones of 30 centimeters. So, two peaks close enough at 30 centimeters are possible to detect and differentiate from, for example, ONT1, ONT2, or any reflection coming from a high-reflective device in that case. Okay. I don't know if we answered this question, but I'll ask it. How often does the OTDR DAS need to be calibrated to ensure proper reporting monitored events, sensing that is read in IQGO? Hello? I think that's one for Patrick. Yeah. If it's an OTDR calibration on the FTH, it comes out of the factory calibrated, and it does not need any more calibration going forward. Okay. Here's one for Stefan. Does IQGO have a – sorry, I'm trying to read the English here. Does IQGO have a mobile update? Is it able to update the network inventory in the field? If yes, how does it manage damage in the inventory and the approval process? Oh, I love that question. So, yes, we have the ability to update, you know, S-builds in real time, right? So, if you go to a location and, let's say, for example, you have a fault at a, you know, at a splitter, and it's, you know, the splitter port's damaged, and you need to repatch fibers to a different splitter port, right? You can, you know, create a design update, you know, from the model app that says, hey, I moved this fiber from this port to this port, and submit it as a design change for approval. Now, how the approval process works, it's completely, you know, the final per customer, right? So, some customers actually want the update in the field to just go into master without, you know, any, like, you know, interaction, because they trust their groups to have the right information. Some other, you know, customers have integrated with a couple of other solutions that use computer vision to just, you know, validate the, and automate the, you know, the capture. And then a smaller number of users have actually put a process in place where basically when there's a design change, there is a ticket or an email generated for, you know, a network designer or a, you know, network admin to go in, review the change, and approve the S-built and push to master. The whole purpose of IQ Geo mobility is to make sure that as changes happen in the field, so the idea of the network lifecycle management, that's how it's changes happen, you're recording them, but you have control about how this, you know, changes are recorded and who has approval over them. And if I may add, Stefan, to this, there's an aspect on test and network certification or link certification that could be very well adjacent to this changes in the field. So if you make any changes on your design and you verify the S-built using a test, OTDR, an OTDR test, and verify your distances and update that and make sure your power budget and upon network, for example, is still compliant, that would be also a good way to look at the benefit of the integration of your test system. with your design system. Great. Yeah. Great. I think some super questions. We've gotten to the end, really, of our 45 minutes. We didn't get to quite all the questions, but we will follow up with those people who had questions. And, again, if you want to have copies of the slides that Stefan and Patrick showed, then just quick before you leave, put a message into the question box that you'd like a copy of those slides and we'll get them to you. Again, when we finish the webinar, you will get a follow-up email with three short questions about how we might be able to improve webinars in the future and your rating on this particular webinar. how good a job you thought Stefan and Patrick did, despite our little technical difficulties. So thank you for hanging in. I apologize for that. Yeah. Sorry about that, everyone. And thank you for hanging in. So we had some great attendance today. Thank you very much for joining us. And if you want to reach out to anyone, please let us know. So thank you and bye-bye. Thank you so much. Bye-bye. Thank you. Have a great rest of your days.