 Now, um, software defined E1, yeah, so, um, as I already introduced a bit, well, E1, T1, TDM is good, all the ISDN technology, where, uh, signals arrived reliably and in time and synchronously and, uh, we didn't have lost packets or reordering or jitter or anything like that, um, and those interfaces are 2 megabit or 1.54 megabit in case of T1 synchronous full-duplex interfaces and they're not much used anymore in telephony since everybody has this interesting tendency to move to SIP, um, since apparently the quality of ISDN was way too high, uh, we had to move to something that, uh, loses, uh, the guaranteed quality at least, um, however, it's still used today quite a bit in 2G, 3G cellular networks even in 2018, so many people don't know this or assume that this is, uh, gone, but in reality it's not. So, where is E1, T1 used in GSM or 2G, 3G networks? Well, basically traditionally everywhere. So, ABIS was over E1 using LAPT-MS at layer 2, A interface was over E1 using MTP, ISAP, uh, between the MSCs, uh, is over E1, uh, then of course the MAP protocol stack is over MTP, over E1, um, and also the GB interface from the PCU to the SGSN was over E1 using frame relay as a layer 2 and, uh, then IUB, uh, over inverse ATM multiplex was also spoken over, uh, for bundled, uh, E1 interfaces to the RNC. So, we have, uh, E1 everywhere, um, in classic GSM architecture. And today, on the ABIS side, uh, not so much anymore, uh, it's, uh, much on the decline, uh, because of course, uh, you have an existing 2G side, you put a 3G or 4G cell at the same site and then you put an, uh, Ethernet backhaul there for your LTE backhaul and then you don't want to have E1 and Ethernet at the same site because that's double the line in infrastructure cost and so on. Um, but lots of BTSs interestingly still have physical E1, not just old equipment from the 90s that basically nobody runs anymore in at least, uh, developed countries. Um, but still, um, you have even if I, what I showed you, even, uh, Ericsson, uh, 2G equipment from a few years ago still only had E1 as a backhaul option. Um, and, uh, then basically, uh, you have this equipment that you need to, uh, uh, convert and that's where this SIU, the site integration comes into place. So you basically have an E1 link of one meter or half a meter between two units at your BTS and then you have IP. So, uh, that's basically what, what ABIS or E1 looks like. On the A interface, it's also very much on the decline. Um, we see this from the kind of requests we get from operators. Uh, I don't even remember how many years ago we last received a request from anyone who would be interested in having a physical E1 interface for A in, in, in the Osmo Com stack. Um, so, uh, 3GPP has introduced A over IP, uh, quite some years ago as an official standard of how to speak the A interface over IP and that's basically what the modern MSC implement. Uh, so if you have a Huawei or Ericsson or whatever MSC today, it's implements an A over IP interface and Osmo BSC now supports this. So, um, we can basically interoperate and there was some posts on the mailing list. You may have seen that some people completely independent of Osmo Com developer community have basically taken Osmo BSC and, uh, uh, established interop tests with a Huawei MSC and it appears to work to some extent, at least. Um, we haven't received any serious bug reports or so. Now in the core network, it looks a bit different. That's actually quite a lot of E1 and T1 still in, in core network. Uh, that's, uh, um, lots of legacy switches out there. Uh, not everyone has moved to soft switches and as well for STPs. Basically, um, we receive a lot of questions about Osmo STP in recent years, uh, because, uh, people want to move to virtualized environments and they can get a soft MSC and they can get everything basically implemented in software, but the STPs, uh, are proprietary hardware from the vendors and some of them are no longer supported these days. So there's, there's E1 lines around there. Um, and, uh, um, also I know that, uh, at least, uh, I think like two years ago or so still new MVNOs in Germany would be attached over real E1 interfaces with the MNOs and not over sick trend links or something like that. So it's still a very common, uh, even for modern virtual operators that they don't use virtual E1 links or something like that. No, they use real physical TDM E1 links to interoperate, um, on those interfaces. So there it's quite, uh, prevalent still. Now in, uh, uh, the lip Osmo Avis, we always had this interface for MSC and in Dadi as we just mentioned, uh, you get PCI and PCI cards, which are still surprisingly expensive. So if you buy even the Chinese clones of Digi Digium cards are rather expensive and original Digium cards are ridiculously expensive, which is maybe fine if you need one or two of them in your, in your core network, but it's not so fine if you need a hundred of them in your radio access network, uh, to attach all the BTSs. And then of course, the PCI card, you need a rather large computer. Uh, the smallest we could find is something like the Circus devices that have one or two PCI or PCIe slots, but even they are rather expensive and it's actually not really needed. Um, and if you look at what this E1 interface looks like, you have your magnetics, you have then, uh, um, a line interface unit, then you have some TDM controller, which attaches over parallel bus to some bus bridge and the bus bridge goes to PCI or PCIe. That's basically how your typical E1 card looks like. And this, uh, TDM controller, how I called it, of course, it's not just a TDM controller, but it even does things like line equalization as elastic buffers for jitter compensation. It has CRC handling, framing, HDLC, uh, processors that do the, the HDLC bit stuffing and so on and the synchronization in there. And, um, well, now we know there are all these, uh, traditional BTSs out there, whether it's the Ericsson, uh, RBS 6000 or other devices, which we could use at a low price, but we don't have a low cost and, uh, easy to use E1 interface. Um, right, uh, because in the end, the E1 card and the PC are more expensive than your BTS. And I think that something is wrong, uh, in that situation. So you want something like an Ethernet or a USB interface between that E1 adapter and your, um, your, uh, your Osmo BSC and, um, that can be used with a laptop if you're doing development or debugging something that can be used with a Raspberry Pi or a Beaglebone or, uh, uh, whatever orange pie or a, um, whatever the names of all these, uh, embedded boards are these days. Um, you just attach that and you have E1 interface and then you have a really low cost, like a sub $100 solution for running, uh, such a BTS together with a BSC or together with a media gateway, um, on, uh, that board. Um, so how do you go about this? Normally you would say, well, okay, let's just use one of those chips here, uh, like the line interface unit and a particular TDM controller, um, and put them on a custom board. Um, uh, the problem is many of those controllers are already end of life for many years. So they're very popular, um, uh, Infineon, um, uh, Falk or QuadFalk chips that you find, uh, on many devices. They are EOL for many years because ISDN is not so popular anymore. And then they have arcane bus interfaces, like parallel, uh, internal Motorola bus, like it's 1980s. Um, and they're rather expensive, uh, and rather expensive means easily 30, 40 euros, uh, a unit, uh, for a chip that basically does nothing, uh, in, in terms of processing or, or logic capacity or something like that. And then they come in very arcane packages and, uh, like, I don't know, 200 or more pin, uh, uh, TQFP packages, like, uh, six or seven centimeter long, uh, uh, chip, uh, um, packages, uh, really, really old. And, uh, so the plan is to establish a software defined, uh, TDM or software defined E1, where we simply use a line interface unit, which is, uh, this guy here in the middle, which does nothing else, but converting this HDB3, this, uh, ternary, um, uh, polarity neutral signal, uh, that, uh, you speak on the E1 line to a serial bit stream on the other side. It doesn't do anything else, but converting the HDB3 to, uh, normal binary bits. And then we go into some microcontroller of whatever nature and then we go over USB or Ethernet into a Linux system. And the idea is that in here you basically do nothing in the microcontroller. You just take buffers of bits and you stuff them over USB or Ethernet and vice versa, and you do all the logic like the HDLC controllers and so on in, in software and you don't bother with link equalization or whatever on, on the physical layer because well, we're talking about one meter of copper between the BTS and the E1 card. It's not about a hundred meters or whatever, uh, where you actually have to worry about, uh, reflections and, and, uh, whatever, uh, cross talk and, and all these things. So what kind of options do we have? Option number A is, uh, Ditas preferred method, uh, is, uh, using a PRU. Um, that basically, uh, not sure if everyone is familiar with what a PRU is or what it does. Um, I'm not the best person to speak about them here. I think we have our resident PRU expert, uh, sitting in front of me, but just very quickly it sort of allows you to do a high speed real time bit banging. You have two separate or one or two separate CPU cores inside, uh, like an AM335X or other TI arm processes, a separate core with a very limited instruction set that you can use for doing basically such serialization, de-serialization jobs. And then you exchange in the end memory buffers with the ARM cores on the Linux side. So you, you offload all your, your bit banging and your, your serialization, deserialization on this PRU. And in the end, you have some memory buffers, uh, uh, DMA like or memory mapped that you use on, on, on the Linux side. And this would mean you could basically use the BeagleBone uses such a processor. So you could have a cape, actually, we could have an E1 cape for the BeagleBone, um, that you just stack on it and, um, you get, uh, support for that. And the, the nice part is the BeagleBone could actually run the entire Osmo BSC and Osmo Media Gateway two, uh, and use A over IP as a backhaul. They have a very nice self-contained small, um, solution. You don't need any, anything else, uh, in, in that approach. Um, my, uh, uh, approach would be, uh, to go for an XMOS device. Uh, I spoke a bit about XMOS controllers at previous years. We've now done, uh, our first, uh, a board design with an XMOS, uh, in, at SysmoCom unrelated to this E1, uh, idea. Um, and, uh, XMOS, uh, basically has, uh, an interesting, uh, architecture in which they have no hardware peripherals in the controller. So there's no I square C controller or no SPI controller and nothing like that. But you implement all of them as soft cores and you have, uh, uh, high speed CPU core at a risk core at 500 megahertz. Um, that has programmable serializers and deserializers and clock blocks around you. And basically you could do the serialization deserialization, um, in those, uh, in those, uh, serdes blocks. And then, um, in the, in the XMOS core, you again, uh, just do your, your, uh, basically collect a couple of those buffers and then send it over, over USB or Ethernet both are available in, in XMOS controllers. But then you would still need an external, uh, like an X86 or ARM board. Next to it attached over USB or Ethernet, which then does the processing. So the, the beauty of the, uh, PRU approaches on a BeagleBone that you really have all in one device and you don't have two devices in the end, even though, well, the strictly speaking, of course the Cape and the BeagleBone are still two boards, uh, that work together. Well, of course you can also go for programmable logic, but then it's not really software defined anymore, right? Um, depending on how you define software, uh, these, uh, defined and you need to work. And I think it's just overkill for a slow, for today's perspective, a two megabits per signal, uh, uh, two megabits per second signal. Uh, you can do that with big, big bit banging and, and, uh, and an XMOS or PRU or something like that. Yeah. So there's some, uh, references. If somebody wants to follow up on, on, um, reading on this, uh, what's the state of it? Well, originally we wanted to start this in, uh, quarter one this year, but as you can realize, quarter one is over by now. It has not materialized yet, but, um, I think we have to do it soonish, uh, because I think the window of opportunity for being useful to people closes. So now we have all this Ericsson equipment out there for a little money. Now we still have people, particularly in, in less developed countries who have an interest in deploying 2G networks. Um, and if we can have a, uh, because so far the Osmo com stack has been used always with rather small cells or femto cells, right? Um, maybe up to 10 watt, uh, uh, uh, and, and single or two TRX, but with this equipment we could really go for a six TRX, eight TRX, 12 TRX, whatever, a large macro cells, um, and, um, uh, have a, uh, sort of fill the gap in there, uh, for a very low cost and help people, the gap filler. Yeah. That's a different, yeah. Who, who still remembers the gap filler in here? Yeah. Yeah. Okay. Well, they at least had boards. I'm just doing vaporware here, but, uh, yeah. And that's, uh, still so, so Tita and I want to look into this, uh, soon and, uh, implement it. And the large part actually will not depend whether it's XMOS or PRU related because all of the software is just software in the end, uh, which controller or which hardware interface you use to get these raw bits of the line into your memory. That's then a small detail. Um, and it's, it's actually the, the CRC for processing the, the TDM frame generation, the, the HTC controllers and so on. That's all software anyway that you can run with any, uh, hardware interface. Yeah. Questions. Um, it's, um, they are the, oh, sorry. Yes. The question was, do I have a link to the, uh, specs of E one? And my answer is no, I do not have a link right now, but, uh, I think it should be in, if you check, maybe the Osmo-com issue or so, I definitely looked at them. They're ITU specs. And I think it's, it might be something like G seven or three or something like that. I don't remember right now, but definitely, uh, the, the entire, whether it's a E one or E two or E three or T one, and all of these, they're all, um, uh, uh, public ITU specs that you can just look at. Let me just, maybe I can find it here. Yeah. It's G seven or three, mainly I think. Um, so it starts with G seven or two, but, um, G seven or three is really the one. Uh, so basically here, this is the physical electric logistics of hierarchical digital interfaces. It doesn't say E one anywhere in the title. Um, but here, actually it, um, if you look at the year here, you see there's the, uh, 64 kilobits and then the, the T one 1.5 megabits and you have the higher bit rates. And then you have the E, uh, yeah, whatever why they call it E 12 here. I don't know. Um, but, uh, this is basically the, um, the series of specs, uh, seven or two, seven or three specs is, uh, what do you want to look at? It's not really not much. I mean, it's, it's very little effort that you have. Uh, one, one aspect that I didn't mention yet, maybe it's worth mentioning, but you always wanted the BTS of course is also a stable clock. So if we actually go ahead and building this, then I think, uh, it would be worth to put a GPS DO on the same board so that the two megabit signal of the E one is really stable. And then you have no clock issues on your BTS as well. So, um, yeah, maybe we can recycle some clock tamer there if you're interested. Um, okay. So the comment was, uh, they're doing a remake of the clock tamer. So, um, okay. Um, good. Any questions, comments? Yeah. Peter has a question if somebody could pass the mic. Oh, Keith behind you. Look behind you as three headed monkey. No. So how, how quick is the turnaround? How, how much time do you have for processing, uh, of bits before you have to turn around? Uh, there is actually nothing really fast. I mean, I studied the specs and I couldn't actually find anything. Um, I mean, in the end, you have of course layer two lefty, which has some timing, but those are on individual 64 case lots. And so you have 30 other times lots that pass until you, you could respond in theory at the first time and the timeouts are rather in the hundred milliseconds or so. So it's clearly buffering should not be a problem there. Um, uh, at least not the kind of buffering you have on, on USB these days. Um, I like the PRU approach a lot. I think the PRU is, is fun. Yeah. As I said, I mean, I'm not emotionally attached to XMOS. I just think it's a good technical match for the problem as well. Um, but as I said, the software will be independent of that anyway. So in the end, we could have both or whatever. I mean, we have to have to software implementation. And I think the particular hardware interface will be, uh, there's, there's many options. I mean, some people could even do it with an FTDI or something maybe, uh, uh, if they wanted to. Okay. Good. Um, then if there's no more questions that concludes the software defined E1 talk.