 Hi, my name is Kashrif. I'm an engineer working at Facebook. And I'm seriously jet lagged, so I might just fall asleep. So today, me and Emily are going to talk about OpenCellular, which has actually been announced that it's going to be released. But you will see there are some files which is just hanging around on our TIP website. So I will talk more about that. So main question is, as Alexander and Harold mentioned, there are many, many base stations out there that are actually designed to work for 2G, 3G, 4G, and so on. So then the question is, why build another base station? And the main reason is, when we actually did our analysis at Facebook, we find out that most of the ruler communities is actually very small and they're very isolated. So you will go to these ruler areas, you'll see a pocket of people, like maybe a kilometer, and then nothing, and kilometer, and nothing, and so on, and on, and on, and it just repeat, and repeat, and repeat. The second thing is, based on our study, is the direct cost of a base station is just a fractional of the overall cell side cost. So when I say cell side, it includes the base station, of course, this is a ruler side, so I'm assuming it's running on solar. It includes the panel cost, includes the battery cost, charge controller, the tower, land acquisition, most of these places overshadow all the electronics. Your security, like your fences, if it's like in a highly not too stable areas and so forth, and then it's also about the operational and management. So one of these sites goes down, let's say for whatever reason, you have to send someone, it costs like hundreds of dollars, and with those hundreds of dollars, your ROI just off the chart, so talking that one particular site. That was the second reason, so we were looking into how we can reduce the overall site cost, not just the base station cost. And the third thing was, most importantly for us was the open source hardware. So as Alexander mentioned, like their UMTRX is open, but we wanted everything to be open. We're talking like mechanicals, industrial designs, plastic, whatever. We're talking amplifiers, I will show in a minute. We're talking motherboards, microcontrollers, every single thing, and we wanted to build and use open-source software. So these are the main three reasons that we started this project. So this is the overall architecture of open cellular, the current version. There is a lot of room for improvement. So this is not the final version and the whole idea is we build something, we want to be open so other people can start contributing and hopefully make it better. So overall, we have three major component and I will go more into detail. The first one we call the GBC. There's a mistake here, but it just take with B, it's supposed to be P. So the GBC is your general base band processor or application processor. Basically, here is running Intel, on the GBC board, which is a board itself, has also an embedded controller, which is based on ARM M4 and it has all the power circuitry is all here. Then the second one is the SDR or is highlighted red because the current version is the SDR, but we have worked on many multiple SOC versions too. So the SDR is basically a derivation of the address B200 or B210. And on the SOC version, we have played with Intel and most recently, Cavium. On the TRX side is right now since based on B200 is basically ADI chip, so it can go up to six gigahertz. And the whole idea was, oh, sorry, awesome. And the whole idea of splitting that was we wanted frequency independent part to be on the SDR and frequency dependent part to be on the front end. And that's where we build the front end. So this is a very specific, that particular carrier base, whatever, like let's say 2G, then it will support like 900 megahertz, 850, 1800, 19 and so on. One watt, two watt and so forth. This is the analog front end. So let's go a little bit more into detail. This is basically, you've seen the picture of the box, we're supposed to bring it back anyway. Is the same thing, the GBC radio, the front end, three main components and then we have other sporting components around it. So for example, we have a sync board and Alex was mentioning the same problem we have with the 16 SDR is the clock. So you need that 0.1 or 0.05 or PPM. So we are using, for example, a GPS DO. It's a part from Jackson lab, readily available. It uses the GPS to sync his clock to the PLL and so on. Also on the sync board is something, going back to the idea that I mentioned earlier is like if one of these site goes down, then it costs like hundreds of dollars. You have to send engineers and so forth. So we have built or use a autoband control channel. This is basically a radium satellite module that just goes on it and is completely optional. So it's a connector that you can populate or you cannot populate, it all depends on you. And the whole idea is this is something we actually learned by our experience is one of our site was in a very remote area and somehow the power got disconnected. And because the power got disconnected, of course everything is dead. We have no idea what happened. Someone stole the base station, it fall of the tree and so on. So we have to send someone like go check it out and it costs a lot of money and time and frustration. Now I'll show you like how we solve that back of power problem. So that's on the sync module. That's again using a radium. We have built auxiliary boards around it basically to, for example, you wanna debug, you wanna like flash like some on the flash drum on the microcontrollers and so on. So that's a debug board that will go on the GBC. That debug basically have all your interfaces, HDMI, Ethernet, USB, I think this is a typo, it should be ICDI in circuit debugger interface, but anyway, now digging more on the GBC again. So we have the computing board which is as I said earlier is Intel 3845, it's a quad core. And we also have an Ethernet switch. It's a 100 MB Ethernet switch and it has a mic and controller and so forth. On the radio side, so the current radio, as I said, it's a derivative of, I think I will talk in a minute, it's derivative of USB, but we have actually added some other interface. So there is a PCIe line going to the atom, but it's not currently used because we don't have software for it and so forth. So on the front end, we have, as I said, like so all the PLA is LNA and Emily will touch upon that in a minute. There's all the filtering, duplexers, couplers, and another interesting thing we added was the GSM loopback. So which is basically a small GSM module that's sitting on the front end and it does a loopback so we can actually, when we upload the patch, we can test the whole thing if everything is working fine or not. These are the basic interfaces and the reason why they're very important because as I said earlier, here we have the SDR and the SoC version. Basically the whole system is designed that you can take the SDR card and put the new SoC card in. Current version that we're working on with Kevium is basically the LTE version. So you take our SDR card and you put the LTE card now it becomes a LTE, like a micro base station, not small cell. All these basic centers are very well defined, is nothing new, it's just USB, GPIOs to control various switches, powers and so forth. There's an I2C line that goes to control various sensors that we have, it has the current sensor, voltage sensor, temperature sensors, so it does the power cycling and so forth. And it has 12 volt, it takes the PoE, which I will actually talk in a minute. It takes the PoE and it takes various power source and convert that into 12 volts. So internally it's 12 volt, we also use five volt, which is for front end because the PA we're using right now is used five volt. And yep, all right, cool. Going a little bit more, so I'm gonna start with the standard like interfaces that we have into the box. As I said, so this is PoE, it takes, it has two PoE port, one is the PD and the other is the PC. This is actually PoE++ from linear technology so it can go up to 90 watts. I mean, it's not gonna go up to 90 watt, but it can. It also sport the passive PoE and is backward compatible with the standard AT and AF. The idea of the second port on the PSC was right now it can only do maximum of 20 watt output. And the reason is because we thought this is good enough so you can attach a ubiquity like a nano station and do like a long distance Wi-Fi and hook up another base station to it. So you don't have to run into the wire up the pole. On the DC input, it takes 16 to 24 as a DC input and can go up to 32, 36. As this is basically overloaded, you can actually attach a solar directly to this base station because what it has is it has built in the charge controller. So, and going back to what I was telling earlier, we have built in two charge controller. One is for seal that acid battery, which is external to the base station. And the other is the lithium ion battery, which is internal to the base station. So this lithium ion battery stays inside the base station and it gives you the power bridging. So for example, if your main power goes down, you will always be in a known state. And if your backhaul goes down, then it use the radium module to ping that what really happened. And then it can use that to state or kick off some, whatever your backup system is. So it has a built-in UPS. And depending on the power source, which is right now is hard-coded. So it is a very, very hard-coded sequence on the power. So for example, when you DC, when your PE is there and the lithium ion is there, the POE take precedence and the POE is not there, DC is there, DC take precedence and so forth. So right now it's hard-coded. So yeah, so the battery backup system can last for this version can last up anywhere between 25 to 35 minutes depending on how you're running your PAs. If you're running at full power, which is right now is two watt per TRX, it will last about 25 minutes on the lithium ion. Right, going forward. Oh yeah, the basic stuff it has two end type because we have two TRX. Again, this is something just ADI chip support and then it has a power switch. On the ethernet, sorry, on the microcontroller, the housekeeping part, as I said, it is basically based on the TI-M4, the Tiva microcontroller. This, right now, it uses 120 megahertz microcontroller. We don't really sure if we need it that much, but we just add it so we can provision it with the swap out the part with the smaller one as needed. This microcontroller, it manages all the power rails. So for example, this is the last man standing. So this particular piece is rated to last up to ambient of 125 Celsius, which hopefully will never happen, but the whole rail, the whole power supply for this is independent of the power supply for the rest of the system. So this always gets up and then it will enable the rest of the power rails one by one. And if something bad, like for whatever reason, like let's say it's 55 ambient outside and internally just happened to be too hot, all these are industry rated temperatures, so it can last up to 85, but you don't want to run them at 85 if you wanna run them lower. So based on the policy, you can shut things down and so forth or never start up. It also monitored the Ethernet switch that I was selling earlier. These are the switch, those two, the PoE ports that goes to the Ethernet switch. This particular part has built in MDI, so that also goes to the Ethernet switch so you can actually ping the platform even when your Intel is not running. So you can actually ping and get the status of what's going on, you can enable, disable, or you can send the ping on the radium module and so forth. Yeah, so monitor the boost sequence is runs our version called OCRA's talk in a minute, which is basically a real-time OS based of TI Autos, which was originally called CIS BIOS and so forth. All right, so this is the host processor, this is one board, this is the GBC board, this is the basic level I was telling earlier, this is Intel 3845, and all this goes back to that connector where your SDR or your radio card connects. Okay, so this is a radio card, and I said like, these are just standard interfaces, USB 2, USB 3, I2C, most importantly, there's a PCIe 12-volt and 3.3, this is the 3.3-volt that is actually on Tiva, so it's completely independent. So even if you are not powering up your SDR, you can still ping various components, for example, EPP ROM to get the ID and so forth. And the rest is basically a standard SDR, so there's nothing really here. The difference between B210, or yeah, B210, and this one is, B210 uses, I believe, Spartan 6, we use Arctic 7, the PIM maps are changed, the clocks are changed, we use a little bit different PLL circuitry, but otherwise, Conceptionally is the same, that's why it's backward compatible with the UHD. All right, and I think Emily will talk about this, this is the front end, one of the RF chain that we have implemented, and then it just replicated on the other, as the second TRX, and she will walk through, so I'm gonna skip that. This is a very, very high-level architecture for the software, what we have right now. So we started with the core boot, so we have basically taking a Minnow board core boot, and change it to work with our motherboard, or the GBC. Right now, all the code is not been pushed into mainline core boot yet, this is still internal to Facebook, because we're still finishing a bunch of testing on this, but all of this will go back to mainline, so we don't plan to fork or any such thing, it doesn't make sense. On the core boot part, then, is the traditional, the BIOS, which is basically C BIOS, not U-boot yet, again, just to make things easier, and then on top of it, internal Linux. We have done some enhancement on the boot loader, around core boot, which is basically, because, let me just go back, one thing here is, yeah, so this guy, the microcontroller, is actually monitoring the boot sequence, so as the Intel boots up, it goes initialize silicon, then initializes ROM, then initializes RAM, blah, blah, blah, it goes through all the steps, so all that is actually monitored by the Tiva, sorry, the microcontroller, which is the severe part. So it monitor and let's assume your M-SATA is not working, it will restart, restart, restart, retry, it doesn't work, it's gonna say, hey, what the hell, something happened, it will start sending messages out on the ethernet port or a radium depends on how you have configured it. On top of it, of course, the UHD drivers that very, very minor modification because the part is different, so instead of Spartan 6, it's Arctic 7, so you have to recompile, the PIM mapping is different, the clock is a little bit different because you use 40 megahertz internally and so forth, so very small changes, not much, but we hope to put it back. And then on top, it runs just a regular Linux on that Intel side. And then on the OC there, which is basically, as I said earlier, and I will talk about this here, is Tivaware from TI, which is open source. We can run on free RTOS because the free RTOS, there's a port to run on the Tiva microcontroller, but we have not played with that. But then again, the Tivaware is open source, anyone can download, it's a free software. And these are all the subsystem that run internally. One other thing I wanna discuss here is the BMS, the battery management system, which is what I was telling earlier, it has two charge controllers, so this is all handled by this microcontroller and again, and so forth. So, and it goes on and UART, you can support UART, Ethernet, OBC is the Out-of-Band-Control data channel, which is that Iridium module, so you can actually ping it from various sources. On Ethernet, on UART, because UART is actually connected to the Atom, and you can ping from Atom, you can ping on the Ethernet port, or you can ping on the Out-of-Band-Control channel. So going back here, so all the stuff that you see on the right side, the OCWear, OCMiddleware, OCCLI APIs, and all this stuff, the software we're still working on, so it's not open yet, but it will be available for everyone. And we do plan to put on the public GitHub, so it won't be just behind anything. And then on top of it, of course, Linux, then we run Osmo. One other thing is, this is since it's a variation of B200, it runs open, Osmo TRX. And yeah. And then on top of it, for the management part, the provisioning of the base stations and everything, it runs the community seller management that Uma is gonna discuss that. That's already open. It's on the fabricator on the, sorry, GitHub, yeah. GitHub, so you can have a look at it. All right, cool. Yes, so now I'm just gonna talk about exciting stuff. Thanks. Cool, yeah. So, just kind of transitioning. So the SDR, the software running on here is, we have the FX3 firmware, which communicates to the FPGA. Currently, the FPGA is really just running the UHD, but we've provisioned the FPGA such that it could do TRX control and gain control of the front end components, which is mostly what I'll talk about. And there's also OCWare running on the front end to configure state like the PA gain stages and some other components that you'll see soon. And maybe just one point to bring up, as Koshif mentioned, so you may notice like, there's kind of like these two separate verticals here. So there's like the UHD driver, which will control the gain stages in the ADI chip. And then there is the OCWare, which will control the gain stages on the front end. And then there's this kind of like a higher layer that ties it all together. So now looking more at, cool, at the front end. And how are we for time? I think we're a bit over. A bit over. So I don't have to go into too much detail here. I think like the main point I wanna make is that we have separated, we have three boards as Koshif mentioned. So we have the general compute board and then we have the SDR board derivative of the B210. And then we have a separate front end. And as Koshif mentioned, the reason why we made that division is so this front end, which is inherently ossified, it is static, it has these filters that are not polyphase, they're not gonna be changing anytime soon. So that sort of stuff is very specific to say the operator or the region you're in can be easily swapped out. But the things that will not change is this frequency agile portion, the portion that works from DC to six gigahertz, which is part of the SDR board. So currently the front end that we're supporting is actually just presently a 900 megahertz board. And it has, it comes with its own particular power levels, noise figure, signal flows, which can be tuned to your specific scenario by just building another front end board. So that's what I'll be talking about here. So just really quickly. So that's kind of where the line's drawn. So this is like maybe, this is transmitted or receive of one TRX, transmitted or receive of the other TRX, and all this is just control. So I think I'll just kind of, oh, I guess I should show that. So the ADI chip puts out normally zero DBM, we have some gain stages, then we have some passive components and introduce some loss. And we have a switch here. And what this switch does is it can send the signal back to this GSM module. So we have a little GSM receiver inside of our GSM, I'm sorry, we have a GSM transceiver for a mobile station inside of our GSM transceiver, which is a BTS. So if you wanna, you know, as Kasia said, make sure that your update worked or whatever, you can just send the signal directly to this little UE, this little mobile station right here. But normally it'll be going straight ahead, assuming along through some filtering and gain stages through our PA to 20 dB coupler, which is gonna always be in the line which just siphons off some of the signal for forward and reverse power detection for this war measurement. We have an onboard ceramic duplexer, which as you can see sucks away half the signal. Three dB loss right there, going to the RX chain. And you know, if you give this thing a 14 DBI antenna, you'll have 47 DBM out. So quickly making a U-turn. So what I'm gonna do here, this is a little esoteric, but I'll just go through this. Oh. So I'm just kind of like tracing through here the noise figure and maybe just quickly like discuss the importance of the noise figure related back to what Alexander was talking about and Harold was talking about, you know, this axis is your receive sensitivity. And let's say this is negative 102 dBm, negative 102 dBm, you know? And ideally, you know, you're down here at negative like 108 dBm and then you can receive even more signals. You can, your cell size becomes larger, but practically the receive sensitivity is often closer to negative 101 dB, 102 dBm. And that's because of this noise figure. So you can basically, when you add gain stages, like this in white is all these gain stages, you're not only increasing your signal, but you're increasing your noise. And each time you do that, basically each time your noise figure goes up, you're reducing your sensitivity. So the way that you get to your receive sensitivity is you calculate the thermal noise floor, which is a function of your bandwidth because it's just white noise integrated over a channel bandwidth. And then you add to that, so let's say in the case of GSM, that's actually close to a negative 120 dBm. So it's way down here. And then you add to that your noise figure. So let's say that's often around like a five dB. So then you're at negative 115, but maybe actually 10 dB on the band edges particularly. So you're more like at negative 110 dBm receive sensitivity. And then that's great, maybe you could receive, I mean, what you still need to do is to be able to decode a signal. So in order to decode a signal, you need to have a signal to noise ratio that will enable the receiver to tell the difference between like a one over here and a zero over here. Well, like if this zero is getting really close to this one, you know, that's insufficient SNR to tell if it's a zero or one. So then you add maybe like five, six dB SNR for GMSK and you get closer to negative 102 dBm. So that's what this number here is tracking. And that's why it's also really important to put your first gain stage as close as possible to the antenna because you notice any passive element like the duplexer or the cable or whatever. So here actually previously I showed the duplexer is 3 dB, I guess it was actually 2 dB. So this is its insertion loss if we assume that we have a zero dB signal. So it's all relative to what's received at the antenna. So dB is a relative measurement. So we have zero dB at the antenna. So then we have this 2 dB down, 2.1 dB down is basically creating a noise figure of 2.1. So this first thing is introducing 2 dB of noise figure. But if you notice through all these things, even like a digital attenuator, which could introduce a lot of loss, the noise figure is hardly going up. And that's because we have an early gain stage right here. So this low noise amplifier basically normalizes the later noise figure insertion losses to relative to this gain stage, which is very high, you know, it's like 20 dB. So that brings me to the end. So yeah, so basically where the line is drawn is actually here. So if you want to not use these components, do something different, you know, you stick with this SDR board and just introduce your own front end. Okay, thank you very much for this presentation about the Open Cellular Project. And thank you. Despite being late, I still think questions one or two. Yeah, back there, Peter. Hey, thanks. How much approximately do you feel like this will save on an installation cost? Not in terms of percentage, but in actual dollars, approximately. So that's very... Yeah, so I wanna give a number. I was, Pierre told us not to give any number, but compared to traditional one is traditional as in, I don't know, I cannot really say. It could be, it's less than 10,000 a site. That includes everything. Yeah, that's the aim, yeah. Any more questions? Tomer, Niels? I found it interesting that you're from Facebook and on the other slide, you had the big brother. So I'm just curious, what is the big brother doing there? I was just thinking, yeah, we actually got that as a joke in there, big brother. Okay, yeah, I noticed it immediately, of course. Okay, one last question, real question. You spoke about RF power measurements in the microcontroller part and that it's somehow connected over this middleware in one of the earlier slides back to the, I say, yeah, well, to the Osmo stuff. Do you have some improvements made in the UMTX world when it comes to power loops, Osmo Trix power loops? So how loud is my BSS, MBT ascending and what is it telling the mobile station how loud it should be? So just a quick correction that'll be more relevant when, well, Omar speaks, but maybe it actually won't touch on this. So it actually doesn't loop back. The control that happens in the front end and the Osmo stack are at this time independent and they'll be like this layer on top that kind of manages how the two come together. But I mean, I think in terms of like power saving, do you wanna speak to that, Kaushif? If is that the question? No, no, not about power saving, but about the regulation, how loud a base station is transmitting that I said statically as an operator, but how loud the mobile station is transmitting that's something which should be loop controlled by the whole stack. And I know we have some issues there. We need to have improved that. And my interest is, have you already done that or are you planning to? So we have provisioned the hardware to be capable of doing that, to be capable of adding like automatic gain control stages and in both RX and TX, but we have not yet implemented that. We're using just the traditional UHD driver at this time. And those types of things, you would wanna implement that in the FPGA, which is right there, like right where the action is, as opposed to in our microcontroller, which would be really too slow to have anything more than an impact of like, you know, drift, more slow, long-term effects. Okay, yeah. As I said, we are behind schedule by 15 minutes already. So I'd like to move towards the next presentation. Thanks again to the open cell presentations, presenters.