 So we'd like to welcome Jesse Rush to the virtual stage. Jesse has been in the wireless industry since 2006 and has been CTO of Bicel's Technologies for the last six years. Coming from rural Wisconsin, Jesse is very passionate about developing technical solutions, which helped bridge the digital divide in rural America. He is also a strong believer in the merger of IT and telecom through decoupling technology like OpenRAN and an advocate for open source platforms like Magma. Jesse will be sharing our first Magma user story highlighting deployment of Magma at Y Connect. Welcome, Jesse. Welcome, thanks for the intro. So I'll go ahead and get the screen shared here. All right, you guys seeing everything fine? Yep. Okay, great. So yeah, to start actually, so the operator that we'll be discussing here is actually an operator that I used to work for before joining Bicel's in Y Connect Wireless. So with Y Connect, it started, the story is very similar actually to a number of wisps in the US, which I believe is over about 2,000 or so. And so Y Connect, it was formed via computer connections, just an IT shop in rural part of Wisconsin, acting as a data center, providing IT support for a number of business customers. And of course, being from rural Wisconsin, there's very limited internet options. So the story began where Y Connect got started, trying to connect all of these under connected communities, which at the time, pretty much were down to dial up for satellite as a internet option. For myself with Bicel's, Bicel's came to market about five years ago. And we kind of had that belief that we could bring cellular technology to everyone, using not just lower cost solutions, but at the time and still to this day, we use what we have as our own Cloud EPC. Now the Cloud EPC does have certain limitations and this is where kind of Magma can kind of step up to deliver a number of feature sets going forward that is something that could not be delivered via the Cloud EPC method. But we will continue to try to be very high level, focusing on the delivery of Magma for Y Connect and how that came about. So yeah, again with Y Connect, so one of the things is with the area was particular in Wisconsin that we are covering, it's very difficult because it's the one area that we call the driftless area and there's lots of bluffs, hills, valleys. It's not something simple where you could just build tall towers and cover a wide area. There's no line of sight in many cases going five miles and such. So the way around this is really just building many sites. So at this point with Y Connect, they are covering over seven counties with 232 sites. The majority of those are gonna be off of existing vertical assets, being silos, grain elevators and so forth. Now because of the very sparse population in this region, it is pretty common that there's gonna be some sites with a very low user count, sometimes as low as say five, but yeah, many of these sites are quite rural and aren't gonna be expected to have a number of users. So the economics of delivering the wireless, fixed wireless here is gonna be a big key. And this is another area where Magma can support this activity. So just to recap kind of on what are the challenges here but what are also the benefits for bringing cellular technology using that for fixed wireless. So not too long ago, LTE was really not an economical, viable solution for the majority of WIS. When you add the cost of the entire RAN solution plus the core network, there was no bridge to even try to enter to do trials to really get there. So, but again, one big benefit for US market, we do now have, speaking of last year, the official launch of CBRS. So that is brand new band 48 spectrum that is truly available to pretty much everyone. So, before the barrier was that it's all licensed bands. Now, prior to CBRS, there was 50 megahertz of NN license, which it was in the 3.65 gigahertz range, 237. So this 50 megahertz was pretty much what the operators were using up until the CBRS opened up a total of 150 megahertz. But at this point, it's even no longer, just like a play for actual operators. We're seeing so many use cases for this private LT 5G now. And from last year, the biggest market we actually saw was the education market where school districts were building out their own networks and trying to deliver internet connectivity to a number of low income areas and the campus itself. So it's no longer just an operator play for whether it's fixed or mobile, but there's many use cases here. But when you're comparing to previously Wi-Fi and still to this day, Wi-Fi is pretty much still the main go-to for fixed wireless. But in comparison with LTE, you do have advanced scheduling, bare support for QS. You also have a much larger UE ecosystem to select from. With Wi-Fi, it wasn't designed for fixed wireless per se or for long distance coverage. So when you look at the vendors that are out there, they add their own proprietary protocols kind of on top of that, say TDMA for example, and they pretty much vendor lock it in. So if you're gonna deploy Wi-Fi from one vendor, you don't have a choice. You're gonna buy the rest of the CPEs from them as well. So there's that advantage. And then we see with CBRS, more and more UEs are coming to market. So that in turn is also lowering the cost as well. And then of course, mobility is something that for Wi-Fi, there wasn't much standard for around that, but mobility is, well, for fixed wireless, mobility might not seem to be as important, but it does provide more additional revenue stream potentials. So where previously maybe just fixed wireless bringing broadband to businesses and homes was, that might have been one of the only revenue streams. Well, now there's potentials as we've seen other speakers talk about of potentially becoming your own MVNO. Perhaps maybe you aren't just selling CPEs anymore. You could be looking at selling more nomadic devices, say like Wi-Fi and such. So there is more potential around that. But as we've seen, there is quite the barrier. The RAN still is more pricey than the Wi-Fi access points, but the biggest barrier that we see, it might not be costs anymore. There is quite a number of UPC vendors. We have the open source projects like Megma. So a number of these costs are certainly going down. So that barrier isn't as big as it used to be, but complexity still is the biggest kind of barrier that we have been seeing. Where when we look at cellular technology, traditionally being an MNO play, they will have a number of engineers on staff that have been kind of trained and even specialized on the RAN or the core network. But clearly there is more complexity involved with LTE than there would be with Wi-Fi. So trying to build up that comfort level for a number of operators, that's kind of really key. And the more automation that can take place and get more to being a service oriented play, the further we get along there, that's going to make the deployments of these smaller operators much more attainable. Okay, so as far as how this project came about, so basically a FreedomFi work together with Wi-Connect to start basically a field trial here. And Wi-Connect is really a pretty good operator to do this with. Firstly, they don't have a lot of per se technical staff and they're pretty Wi-Fi entrenched and focused, but they've had a few deployments with LTE but never quite got that training or knowledge or comfort level to really go mass deploy. So they would essentially just put LTE in areas that they needed better coverage, especially in situations that were more non-line of sight. But for a true build out to build that comfort level, because whenever there were say issues of troubleshooting, you're kind of lost as far as what could be the issue. So having the FreedomFi team and work together with Wi-Connect that really helped build that comfort level and by them really working together to set up these access gateway hardware to provide to them and have it more plug and play, there wasn't much configuration necessary on the Wi-Connect part. So all they really had to do was simply install one of these gateways, go through a couple of procedures and away they went. And from that point, once they're pretty comfortable with that process, they've been able to go time plus sites fairly quickly. But the main goals here were one of the redundancy, one of the issues with the CloudyPC, of course is that your control plane is required to keep the Bs and UEs up. And when that control plane's going across the internet to in our case, it was Azure servers, there could be any kind of disconnect, whether it's locally on the old network or the public network, of course it was susceptible to that. And add on top that generally in a Wisp type network, there's a lot of microwave back calls and during certain periods of high congestion, there could be high delay. So there could be some flapping with the S1s. And so by bringing that access gateway and essentially the MME to the tower itself, really resolves that problem. Multiple APNs, that was another limitation. We only supported the default single APN and with the CloudyPC. So Magma, of course, with the later versions here can support multiple APNs and be able to split that out to different VLANs as well, which we'll be talking about. Network bridging, that is another key thing for migrating, say from a Wi-Fi network to an LTE network that usually has another gateway involved. Bridging isn't something that was supported previously, but obviously with Magma, that's been something that's been more seamless. So now you can just simply set an APN to be bridged so that the DHCP, an external DHCP server can be assigning the IP addresses, which is what is generally desired in an ISP network. And then a couple other things to, we needed to maintain the OMC connectivity by maintaining that connection. One, it's required for CBRS now, since it's using a domain proxy method, but the other is just, each vendor, whether it's buy cells or anyone else, they're gonna have their own EMS solution. This is what's gonna be handling the software updates, the managing and monitoring of the equipment. So we do want to maintain that connection. When Magma was first deployed, there were some issues there, which were later resolved, but that was one key piece. And then in the case of WiConnect, they also have a more vendor agnostic NMS. In their case, they were using Nagios. So they wanted to make sure that Nagios was able to maintain connectivity to monitor the equipment. And this is kind of a high level view of where we are at stages. So essentially the first stage here was to simply set up one access gateway, one test CPE, make sure the connectivity, everything was set up and working well. Once we got that part working, we did have to wait for a new Magma software update. I believe at the time was version 1.2. Once 1.2 is released, multiple APNs were finally supported. They are two bridging was supported. And so that was really key to move things to adding some live subscribers on a live tower. At that point, the next stage was really to migrate all the existing sites to Magma. And once that was accomplished, we pretty much achieved all the main goals we're set to achieve. And after that have been still in the progress of, but have been actively installing a number of new sites using Magma EPC access gateway for each site. Okay, so the initial gaps when all this got started, again, one was that there was only one SGI interface supported on the Magma side. So this was again resolved in version 1.2. After that was accomplished, we are now able to add multiple SGIs and be able to set a separate VLAN for each one. And then the next, of course, was bridging. So again, 1.2, we got that working. So once those first two really resolved, that's when the more mass deployments were started. And then the third here was when we initial started, we also couldn't access the Enome B. So pretty much there is no monitoring capability and we could not directly access the Enome B as well. So that became an issue as a lot of the configuration of the Enome B and troubleshooting of the Enome B is done by directly accessing the Enome B web interface or SSH port. And in the case of the Magma's initial design, that was all hidden behind a mat. So we are able to get past that by adding some port forwarding rules and the new Magma software does allow for other setups as well. And then OMC connectivity was another issue. And there's a new function that got added called external Enome B management that can be set for the radio when it's added to Magma. But by doing that, it allows the forwarding of the TR69 packets. It won't do any hijacking of that. Okay, as far as the network build out here, this is the equipment that was being used for the YConnect LTE network. On the RAN side was using the Bicel's Fortress Q and Bicel's, you know, Cat4 and Cat6 CP radios for Core Network, Magma provided, FreedomFi provided access gateways and they were also hosting the orchestrator. And for the management in their case, it was using the OMC Nagios and for their Billings and CRM, they were using OpenSphere Suite CRM from there. It's a very developer friendly, developed basically, we called it an AP module within there that does API calls to Nagios. So all of the actual radio information is inputted into the CRM. That gets an API called to Nagios, which creates all of the different hosts that are being monitored. So as far as the typical site, this is kind of the standard that is being used for the majority of sites depending on user account. So this was the most economical route found as far as trying to provide 360 coverage as much as possible. Initially they were using, before the project here, they were using Omni antennas, but the performance just wasn't there. So we ended up using two 120 degree sectors. And while it might not sound like it's 360 coverage, when you look at the plots from the antenna vendor, you can see that, with the exception of the, the very edges here in between the sectors, it might not have the same coverage there, but it is still, for the most part, 360 degrees here. We call this the butterfly configuration. So for each site, we would have one B. And to specify on this, on the B, this is just one unit. It's the RU and BBU all in one, such as a small cell radio. So you have one radio installed. You connect it to two, in this case, KP performance antennas. It's a four part radio. So you'd have two cables running to each separate antenna. And then it's set up in dual carrier mode. So each sector would have its own independent cell. And then of course the Megma access gateway would be installed at the tower site as well. Okay, this is just a kind of high level. Like if, you know, what its network setup is for each site, for the most part, this is a more generic IP configuration here. But in a sense, the access gateway, you'll have the two parts here. One is a northbound that goes towards the orchestrator, one southbound toward the B network. So you have on the northbound side, you'll have your management IP. And then in this case, we set up two APNs to split the traffic. One is for the internet traffic, for the user, just general internet, and then one's for management. So the management is necessary to allow connectivity from the dock to be able to access the CPEs. So, you know, this is what's with fixed wireless. It is a little bit different with typical mobile network. The fixed wireless, the difference with the UE side is that the operator owns the UE. So they need to be able to monitor, get any kind of alerts if there's degradation of signals, disconnects and so forth. So we do need a separate network to be able to manage those radios. So in this case, we have the two APNs. So this is a pretty general setup that most WIS will be using. There could be other APNs, maybe you split up your phone and other SIP services, for example, but in general, you'll have the two APNs here. But the big benefit with the bridging support now is that the actual router behind the CPE can just do a simple PHP request and be able to get a DHCP assigned from an external DHCP server. So this, the behavior is actually very similar now or the same as to what someone would expect if they were just to throw up, say, a simple bridged Wi-Fi AP. So, you know, that removes the complexity for sure because we don't have to worry about having a separate configuration for the network and how do we, you know, design the network around that. So all those pieces got removed with the smigma setup. So this has made the deployment much easier. Another topic that I think is important to discuss as well is it's important to know what are the economics that a WISP is looking at when they're deploying sites. The majority of WISPs are self-funded, so they do need to pay attention very closely to the ROI for each site that's being deployed. And, you know, considering that the majority is gonna be pretty rural, you know, with a low user count, keeping the cost down is quite important. You know, so this is just pretty general. There's a lot of ancillaries and other things that are not being accounted here. You know, as noted, there's a number of overheads and engineering services is not part of this as well, but this gives you kind of an idea of, you know, per site that's being deployed, what are the different costs we're looking at? And this is just from the LTE point of view. Now, these costs could be brought down further. There's different base station options, for example. You know, there's radios down to as low as the sub $1,000, you know, if you're looking for, there's like a POE powered, we call it Nova 227. There's just single carrier radios that are at a lower cost point. So there are ways to bring this down. The backhaul pricing could also be brought down a bit too, if needed, but this, you know, overall this gives some general pricing. And this is all list, right? So the actual cost, this is US pricing, list pricing. So the actual cost that the operator would spend is likely gonna be less than this as well. But again, this is quite high level of what we're looking at. So looking at those costs from the previous slide, you know, we can try to try to estimate what is the ROI that we're looking at here. So, you know, for 25 subscribers, which, you know, would probably be an average site, but, you know, it could still be less than that. What we're trying to achieve, the first thing that you look, that an operator is gonna look at is, you know, what can they use that's already existing? In Wisconsin, there's lots of farmland, there's generally some farm silo and so forth that could be used. That's, you know, probably 80% plus of the sites. So that's gonna be the first, you know, option that we look for. And in this case, you can see that even with 25 users, the general thing that an operator is gonna look at is trying to get ROI around one year or less. So that is, you know, for the most part achievable, you know, if you have, you know, only a 25 user account. But when we look at, you know, what if there's an existing tower? What if we rent that? What if we build our own tower? You could see that ROI really gets up there. And at that point, it's, you know, the economics maybe don't work out quite as well. But if we bring out, if we have a more, you know, somewhat more dense subscriber base, you know, that's where the tower rent, building your tower, those can start to make more sense. But, you know, depending again on the number of users, you know, that's gonna dictate the ROI and potentially what direction we go. Okay. So the rest of the slides here kind of just overview quickly what the process, high level, what the process is to onboard the equipment, you know, the products here starting with the Magma. So for anyone to get started, to deploy the orchestrator is gonna be your step one. Obviously you can go to GitHub, you can get the procedures for deploying one. In our case, so for Y Connect, Magma was being used. So they just set up and manage that by themselves. And then as far as once you get that set up, so you would log in to a brand new Magma orchestrator, you would simply create a set up a name. And then the process that's laid out is gonna be what follows that Y Connect used. So for Y Connect, the IP allocation was set to DSP broadcast, that's what enables the bridging. And then enabling multiple APN, and then setting your typical PLMN information. And then for configuring the RAN settings, one thing that might be confusing at first glance with Magma is that there is RAN parameters and configuration within the web UI, which reasoning I think prior was that the Magma would actually redirect the DNS for the TR69 and actually kind of take control of the parameters as far as setting those up. So that Magma does have the ability to actually do all of your RAN configuration within the Magma UI as well. But in the case of Y Connect, we did not follow that. We kind of just, you know, you can still program the RAN settings, but in Y Connect's case, we did not use that. So once you have your orchestrator set up, this is more looking at the HSS point of view. The next thing you'll do is you will create all your APNs. So in the case there's two APNs set up, it's a pretty simple process. You just set up your APN name, you give your amber configuration, essentially what's the default rate limit you want for that. And then we use management and internet. After that, you would import your subscribers. So this is all your SIM card data. If you're migrating from Cloud Core, you could just export that data and then import that right into Magma. And then for Magma, there's the option of manually adding the SIM cards one by one or using the import method. For the gateways itself, so this is in Y Connect's case, one gateway was being deployed at each tower site. You know, you could easily test it by just putting it on any commodity hardware, you know, using the GitHub link here. For FreedomFi, they do provide some gateways and that's the easier route. And again, that's what Y Connect was using. So yeah, again, you know, we just deployed one FreedomFi per tower site and those were already kind of pre-programmed and designed to be zero touch. So just simply deploy it and then, you know, connect it to the network. And then the only really manual thing that we were doing is configuring port forwarding which was allowing access to the, you know, B. So once you've deployed the actual gateway, there's really only a couple of steps you need to take from the orchestrator. So you would log in, you would create the gateway, you know, we set the NAT being disabled was one setting and then you would assign the different APNs which would be associated with that gateway. And then for the management VLANs, there is no web parameters that you can set at this moment. So you would just edit the JSON. It's not too difficult, but in our case we would add the SGI management interface VLAN information here. This was for the management VLAN. So once you have your orchestrator has been set up, you've added an access gateway. The next thing is configuring the, you know, B to utilize, you know, to point to the new network. So there's really actually four steps really needed to make that happen. So one, we would set the WAN to be DHCP since the access gateway was assigning the IPs directly to the, you know, B and then we increased the MTU. This is to allow the additional overhead. And then the next was the MME pool and IPsec. So by default with an advice, you know, B these will be enabled because it's pointing to the cloud APC out of the box. So you would just disable the MME pool and IPsec. You would have disabled the LGW. LGW is the local gateway. It's a local breakout type function. So out of the box for the Bicell's, you know, B it will connect to the cloud APC, but the actual user plane would reroute to the, you know, B itself. But for the purpose of Magma and once you, you know, go to kind of a third party APC, you will want to make sure that's disabled. So all the user plane traffic is sent to Magma as well. And then lastly, you would just simply program the MME IP. And then if the PLMN is changed, you would set that up as well. So you would save, reboot and at that point the, you know, B is done. And this can all be done straight from the, you know, B web GUI. From orchestrator at that point, we just add the, you know, B. We set, make sure that external managed is enabled that way that it can reach out to the OMC that there's no DNS hijacking taking place and rerouting it to the, you know, BD service. And then attach the, you know, B to the gateway. This is all done within the orchestrator. So you basically set a relationship of the, you know, B to which gateway you're using. And yeah, really that's about it from that point of view. And lastly, the CPE, it's pretty simple. You would just insert the SIM card. Of course, make sure the SIM card is already provisioned in the orchestrator. You would access the CPE web interface and program it to be one disable the built in DSP server. So it's not assigning a DSP on the LAN interface. You would set it to bridge mode and then you would configure your two APNs. At that point, the CPE should be getting an IP address from the external DSP server on the tower network. This is just quick screenshot from Nagios. So these, so for Nagios integration, all we really did is make sure that we added the different SMP checks for each OID. And then we made sure to add link, add to create the services and then link them to the different hosts. These host names are basically for the sweet CRM. The sweet CRM, when you're adding the different Bs, you would set which host group they belong to. And then the API calls will automatically create the host and link it. So from the Nagios web interface, it would show something like this where it shows all the different metrics that we're trying to monitor. So this was the kind of the last piece of the project that we wanted to do is make sure that their third party NMS was also monitoring the equipment. Okay, yeah, I guess that's about it.