Welcome to my presentation, LUTO-SDR, the making of an ultra-low-cost high-performance Linux-based software-defined radio. My name is Michael Henrich. I am software engineering manager at Analog Devices in Munich, Germany. Let me introduce a little bit the story behind the ADAMLUTO, which is an active learning module. It is part of the educational program at Analog Devices, and it's meant to introduce the fundamentals of software-defined radio, RF radio frequency, wireless communication, embedded Linux, FPGA, HDL development, open-source software and open-source hardware to basically everyone. It's designed for users at all levels and all backgrounds. And one of the most important things, it needed to be low-cost so that it is student-affordable. To the right, you see that software-defined radio requires multiple skill sets from RF design to digital hardware to signal processing and software development. The LUTO-SDR is meant to be a platform to practice and to develop those skills. So what were the early-on requirements for this device? In order to be student-affordable, it needed to be a low-cost, also a zero-cost ecosystem. That means that there's no cost involved in order to build or use this device. It needed to be open. When I say open, I mean open hardware, schematics, Gerbers, open firmware, basically all the HDL, the bootloader, Linux, the user space, open host so that it is kind of a cross-platform with open drivers and open libraries, and of course also open applications, for example, new radio, MATLAB interface, SDR, ANGEL, GQRX, etc. It needed to be reliable, fail-safe and brick-free. That means if you encourage students to build custom firmware blobs, you need to make sure that you don't get returns because they screwed up the bootloader or anything else. It needed to be high-performance and fast. I'll talk about this a little bit later on. Intuitive, ease of use, supportable, extensible, flexible, and of course cross-platform so that people can use it on Windows, Linux, and MacOS, for example. What's inside? The Pluto SDR uses a Zynx 7000 FPGA from Xilinx. That is basically an FPGA plus ARM Cortex A9. It has 512 megabyte of DDR-free memory, 32 megabytes of spy-nour flash, USB-ALP5, and of course the 1893-63 RF transceiver from analog devices. It can capture RF data up to 61.44 mega-sample, and it has an allowed tuning range from 325 to 3.8 gigahertz or with unknown specs between 70 megahertz and 6 gigahertz. As you can see, there are two LEDs on the bottom, a tiny little button, and two USB checks. One is connected to the on-the-go port, and the other one is just meant to provide auxiliary power in case a USB host function is connected to the on-the-go port. In addition, there are some spell pins that are connected to the FPGA fabric that can be used for designing custom logic or to integrate it somehow into your use case. There is a Chatek port, UART pins for the console. There are some other spell pins over here that are connected to the transceiver, and of course there's an RX and the TX antenna port. The PlutoSDR runs Linux inside and uses the Linux Industrial IO framework to expose IQ data and control. It appears as a multifunction USB device to the host if you plug it into a PC with native IO over USB using function FS as a serial over USB using the CDC ACM layer. It has an R&Ds Ethernet function, a mass storage drive, and it also supports device firmware upgrade. If you use it as a host, there are a range of device drivers built into the firmware for Ethernet, Wi-Fi, audio, human interface, device, and mass storage. It is cross-platform so that it can connect it to Windows, Linux, or Mac PC. Like I said, it uses the IO framework and also the LibIO. The concept of LibIO can be seen over here. There are basically on the bottom IO devices, and then there is the library running on top of it. It communicates through the local backend with the Linux kernel and provides a high-level API to the user or to client applications that run on top of Linux. In addition, there is an IO daemon server that also runs on the Pluto that provides exactly the same interface over a network or USB link to a remote library running on a different computer. This is completely transparent to the user, so the client application running over here doesn't really know whether it's talking directly to the hardware or through a network or USB link. On this slide, you see a top-level block diagram of the system, simplified, of course. On the very bottom, you see the AD9361 RF transceiver, which is connected via some spy interface, some GPIOs for control, and high-speed CMOS interface with the FPGA. Inside the FPGA, we have several HDL cores. There are some hard macro cores for spy and GPIO, but very important here is the AD9361 transport layer core. The transport layer core connects via DMA to the Linux system. On top of Linux, we have split the management of the transceiver into three different drivers. One is called the AD9361-5. The purpose of this driver is to configure the transceiver, to set up the yellow frequencies, to do all the calibrations. Basically, everything you control over spy and GPIOs, then you have two other drivers. One for each direction, one for RX, one for TX. That's basically the capture drivers that manage the high-speed data transfer to and from the device. All in common are that those drivers are IAO drivers. Important to mention are the different other subsystems. These drivers register with the clock subsystem, for example, that allows, for example, the RX transport layer driver to know its sampling frequency and so forth. I talked about IAO. What is IAO? It's the Linux Kernel Industrial Input Output subsystem. And it's really not just for industrial IAO. It's basically for all non-human interface IAO. This can be ADC stacks, accelerometers, gyros magnetometers, humidity sensors, pressure rotation, and so forth. It's in the upstream Linux Kernel for more than 10 years now. Why do we use IAO for software-defined radio? It has a lot of advantages. It provides a very good hardware abstraction layer, which allows sharing of infrastructure. It allows the developer to focus on the solution and enables application reuse. Also, kernel mode drivers have very low latency access to direct memory access interrupts, memory mapped IAO, and so forth. All that being said, IAO provides a fast and very efficient data transport from the device to the application, from the application to the device, and also from the device to network storage. Why is fast and efficient data transport a SDR requirement? Think about the Nyquist theorem, that sampling of 20 MHz of real RF bandwidth, for example, that's exactly 88 to 108 MHz for FM radio, produces a constant data stream of 80 Mb per second at 6-in-bit samples. The Blur SDR maximum sampling rate is 61.44 Mb, and that would require a memory bandwidth of up to 245 Mb per second. And this is way too fast for any USB 2.0. So, first of all, it's very important that we have very efficient low latency zero-copy data transfers. IAO supports two types of interfaces. A low-speed interface, typically used with low-speed converters connected via a SPI or iSqc, and a high-speed e-mail-mastered interface, typically used with memory mapped devices. So, this being said, IAO is used to copy the data from and to the device or to memory. On the application side, the user uses mem-map to make those data available in the application. All this is zero-copy and allows low overhead high-speed data captures. Data is grouped into chunks which are called DMA blocks and the kernel driver manages just the ownership of those blocks. So, either the application or the hardware owns the blocks. The samples per blocks are configurable and also the number of blocks in the queue are configurable as well. So, this allows to mitigate the typical producer-consumer problem and to bridge some gaps if the user application requires some extra time during one block to process. When connecting such a device to a computer, the user doesn't want to wait a minute until the device is booted and is available. So, fast boot was a concern for us. So, there are many good recipes and, of course, there's no one's size fits all, but in general, less is typically more. So, what we did, we slimmed down the kernel size by removing unnecessary kernel options. In addition, we slimmed down the root file system size. And a good way to do this is to use lightweight things. For example, busybox, a multi-call binary that includes all the typical commands, shell commands. In single binary. Then we use a very lightweight init system just with ETC init tab and some ETC init d shell scripts. A very lightweight mdev implementation. The other thing that significantly reduced boot time was to use silent boot. In the kernel, you can specify this in the kernel command line with quiet and lock level equals four or even below. And in U-boot, you just set standard out to null def that prevents any writes to delay the boot. In addition, we used a initial RAM disk which is also pretty fast once it is inflated into memory. And last but not least, the typical thing, you want to set the boot delay in U-boot to zero. With all these measures, we got down to less than three seconds. And I think we just spent like one second booting Linux and the other two seconds we spent in the first stage boot loader and in U-boot to checking the fit image and inflating it into memory. So if you deal with an embedded Linux device and the user treats it like hot block removal that they just pull out the USB cable out of it, you want to avoid fast system corruptions. And we are doing this by actually just using a RAMFS. And on the other side, we restrict the flash memory write access to really the bare minimum. So we allow it during firmware upgrades and during U-boot environmental manipulations and storage. For example, we save a few things in the U-boot environment just like the host name or the IP address. In the last firmware release, we have enabled an auxiliary partition that we had in there. We have reserved one megabyte. It was called the partition used by a non-volatile memory file system. And we used the JFS to file system on that. And we use this to store persistent SSH keys or password changes and nothing else. In addition, as I said before, we need to prevent the user from accidentally deleting our fail-safe mechanism, our bootloader. And therefore, we use flash block protection on the first megabyte of the Spinoff flash. Then we have several fail-safe mechanisms. For example, one is if loading the fit image fails, we automatically enter DFU mode. Then there can be still the case where the user by accident erases or the U-boot environment or more problematic here is to just delete an important variable, maybe something that's related to booting from SpyFlash. We need a recovery mechanism for that as well. Like I said, on JFS 2 we just have things that are not really important and if they are lost, they can be replaced. But we have an additional MD5 checking mechanism on all the files that we actually put there. So before we copy the SSH keys from the JFS 2 partition back into the RAM disk, we check the MD5 sums and if they're not okay, we just don't copy those files. I mentioned the flash block protection feature, often called flash locking. It is a feature of the flash in question. We use Spinoff flashes and those devices often have, depending on the vendor, either a top or bottom protect and depending on the boot mode of your SOC, you basically require bottom protect because it starts executing or pulling data from block zero at address offset zero. Like I said, it is really vendor specific and the block protection bits are non-volatile control bits. That means if you power cycle the board, you're still being set. In the kernel, the driver's empty disk by NOR preserves those bits, so it's not messing with these bits. Where do we set those? If the kernel driver doesn't handle those, we kind of set them in U-boot during factory programming and there are ways to actually clear this if you have access to the U-boot root console. On the right, we see this bottom or top protect. It's basically you can protect the number of blocks and starting at block zero, it's one megabyte and the next block is two megabytes, four and so forth. During our development, we actually found the need to instruct the bootloader to come from the kernel to do something different. For example, let's enter DFU mode on the next reboot without pressing a button on the device or to enter a special DFU mode. We call it DFURAM mode and that is a really, really fast way to load a new firmware without flashing it. It just writes it to memory, it's very, very fast. Or to just halt in U-boot so that you don't need to press Ctrl C while system boots and hopefully you can bypass the boot delay check and get to a prompt. Or just to start the system with messages printed to the console so that you see what might be going wrong because the default boot is silent. Normally you would use FV-SET-INV that's kind of a U-boot tools command that allows us to manipulate or read and write the U-boot environment from your Linux kernel. But like I said, we want to restrict U-boot all kind of flash access, write access to the bare minimum. So we take a detour here instead of using the environment as the messaging variable. We use a general-purpose read-while field in the system level control register that preserves through all the different types of resets, except power-on-reset. That's power-on means really take the power away and reapply it, but it's still there if the reset is caused by a software reset or a watchdog reset or something else. And also this bit or bit field must not be modified by the bootrom or the hardware. So we have created this tiny little shell command that just takes an extra argument. For example, ram-sf-reset or break and writes the code to a CISFS file which is situated close to the SOC reset software reset. And it kind of puts it into the register and in U-boot we just pull that value back from that register and do the appropriate action. For example, if this register has a free in the lower nibble, we execute defu-mode for flash. If it's a 7, we do the verb-boot boot and so on and so forth. U-boot is in general pretty good. If the U-boot environment is corrupted then it just switches automatically to the default environment. And the default environment is kind of a compile-time environment, typically defined with a set of strings in U-boot. So if the CRC doesn't match, it automatically uses that. But what happens if the user has deleted a essential variable and that's causing U-boot not to boot? Therefore, we kind of have the fail-safe mechanism. So that's some of the early init code in U-boot, this is where it talks in. If the button is pressed during boot we instruct U-boot to also use the default environment and this default environment has all the U-boot scripting that allows it to enter defu-mode again to flash a new firmware or a new environment. So the control and interaction concept is pretty interesting. So the question is how to control, configure, or interact with a black box device that only has a hidden button to LEDs and use beyond the Go check. So many things, we have a Bari Zero Conf, we also have a Web Server running on there. Those are typically the recipes that you know from your DSL home router or Wi-Fi router. There's also some LEDs for sign-of-life or state indication that we use. There's a serial console and also SSH, but that's typically just for the expert users. You could do more with the button, maybe Morse code, it's probably a bad idea or to implement a special USB function and create a GUI for it, but that also is a pretty bad idea. So what else, and let me show a short video on how we interact with this device. In this video, I want to demonstrate the use of the master drive on the Pluto SDR.  If you open that drive, you will see basically three files. One is the main landing page. It's an HTML page that gives you an overview of what this is all about, how to get started, where to download drivers and software. It also links in a few third-party support applications. It has a firmware section, how it actually works. There's some embedded JavaScript that contacts the GitHub API, checks for the latest version, compares the current version of your firmware with the latest version, and then allows you to download a new firmware. You just download it to the master drive, inject the drive, and it will automatically flash. Besides that, there's also some version information, a serial number, what kind of version of Linux it runs on, what version of Lib.IO, what compiler has been used to build the firmware. And there's also a link to the sysroot, basically the buildroot sysroot. It allows you to externally build compile applications. You link it against the sysroot, and you just copy it over to your target. The password, some information about the IP address, and a few other things. But at least there's also link on how to get help and support. The other file is basically the legal information of the device, the written offer, what kind of software it uses, what versions and what license are those packages. The most interesting part is this config file. It is an in-ease-style file that allows you to customize certain settings of your Pluto. This is in particular important if you want to connect multiple Bluetooth to your PC at the same time, so you can assign them an individual hostname, give them another IP address, and there are also some actions in here. For example, you can generate a diagnostic report. So what you do is just set this to one, save the file, close it, and then it checked your master strive. It immediately comes back and has the desired information. For example, this diagnostic report, open it, it includes all kind of version information, the kernel startup messages, a lot of information that's useful, debug, IO info, the UWOOD environment, the processes that are running on, and so forth. All that can be useful for debugging.  What's required for this? It requires a backing storage. It's basically a block device, or in our case, it's a regular file. This regular file needs to be full-sized, so you kind of create it with DD, then you create a partition table within that file, and then you also create a file system in that. For cross-platform support, we decided that this file system need to be fed. That's really a very common thing because it is cross-platform. But the problem with this, and you might have noticed our detour using the eject button, is that this file can't be accessed, loop-mounted, etc., while it's being attached to the mass storage gadget, unless it's read-only from both sides, which would be totally pointless. So how does it work? The backing storage, in this case fed.emg, between the USB mass storage gadget and the Pluto. In order to assign the storage to the mass storage gadget, you basically write its file name into a config.fs variable over here. USB gadget composite, gadget, blah, blah, blah, loon file. In order to return ownership, the user on the remote side needs to eject the drive, and this is done by some SCSI eject command that is typically present on all operating systems. It is very similar to ejecting a CD-ROM out of a CD-ROM drive. Once the backing storage is idle, not owned by the mass storage gadget, we have a kind of a daemon or shell script running on the Pluto, which loop-mounts this backing storage and checks its contents for, let's say, a new firmware or for some manipulations on the config file. We kind of do the appropriate actions, flash the new firmware, and once we are done, we assign the backing storage back to the mass storage drive. So while we are flashing, we need to give the user some indication that something is happening on the system so that the user doesn't turn off power or pulls out the USB plug. And we do that by using LED triggers. So in Linux kernel, there is a LED subsystem. It's called, like, LED glass. What it basically does is it allows the users to control LEDs from user space. That's our control via files in SysFS under SysClass LEDs. LEDs have a brightness attribute, which sets the brightness of the LED between zero and max brightness. For LEDs that are controlled by GPIOs, every value greater than zero will turn the LED on. But more interesting here is the concept of LED triggers and triggers are kernel-based sources of LED events. So during normal operation, we use the heartbeat LED trigger, and that is kind of a nice flashing LED, and it looks similar to, like, a heartbeat. And if the system load goes up, it beats faster. So you know what's going on on the system. But while we're flashing, we want to get a better indicator. And therefore, we use the LED trigger timer, and we kind of let the LED flash really rapidly so that the user knows, oh, yeah, something is still going on. I better don't turn off power. In order to use those, on the right, we see a device-free snippet. You set compatible GPIO LEDs, and then under this node, you can define a number of LEDs. LEDs have labels. They have a P-handle for the GPIO that they control, and, of course, they can also have a default trigger. In this case, it's a heartbeat. So when the system starts, it automatically enters or uses this heartbeat flashing thing. From the user perspective, it's Sys-FS stuff. You write strings and values into Sys-FS attributes, and these are the two shell functions that we use for flash indication on and off GPIO keys. Like I mentioned earlier, we have this kind of this fail-safe mechanism where the user can press the button while it's being on, and that lets the bootloader enter like a DFU mode. We also have something similar in the Linux kernel, and therefore we have this GPIO connected to the GPIO keys driver, and the GPIO keys driver translates GPIO all interrupts into Linux input events. So these are Linux subsystem input events. And on the Bluetooth system, we use an input event theme that also is part of busybox to invoke certain commands based on these input events. Here it's very similar. You have a device tree, a node with compatible GPIO keys, and then you have a number of nodes for the different buttons in your system. Again, also a GPIO handle and some sensitivity and what kind of input event code or Linux code should be sent to the input subsystem when this button is pressed or not. In this case, we use button MISC. On the Bluetooth system, in basically user space, we have this input event theme in running, and this is kind of the configuration file for it. It has two sections. One is global, it should listen on DEF input event 0, and the button keys that it should do something with, and in case the button 0 event comes, it sets action to remove all and then calls this slip MDEF auto-mounted script that I will talk a little bit about on a later slide. Here are some tips and tricks about multi-function USB gadgets via config.fs. This is kind of something that has cost me quite some headages. In general, USB gadgets are seen as a set of configurations. Each configuration has a number of interfaces also referred as functions. So sometimes the order of those interfaces really matters. For example, Windows requires that R and D is always on interface 0. If it's not on interface 0, really strange things happen, and it all doesn't make any sense. This being said, it's just some heads up if you compose your own multi-function USB gadget. Some other tips and tricks around gadgets are here. In order to distinguish between different devices, the serial number stored in the device descriptor must be unique. So you think about you have multiple of the plurals connected to your computer, and you want to distinguish between them or have always comport 0 attached to the same device. Even if you plug it into a different port, if you don't have a unique serial number, you will get 145, and next time you plug it in, you get Comport 146. That all is not really nice. Therefore, get a unique serial number. This is where the problem begins. Assigning a unique persistent serial number is kind of expensive. If you would need to add some additional eProm, that adds costs to the problem, you would need to program that. You would also need to make sure that you don't program the serial, the same serial number twice. This is all kind of infrastructure. We looked around and actually found that the Spy Norflash has a unique ID code. That unique ID code is right behind the JEDEC manufacturer and device identification. It's not present on all Spy Norflashes, but MicroN has it. This is really useful. It's a 6-in-bit unique ID. What we do is that we kind of just read this and print it to the kernel console or the kernel message when the system boots. When we create the USB Gadget, we just parse, use Crap on Dmask, get the Spy Unique ID string and assign it to Gadget string serial number. That works pretty nicely. The USB host functions. The USB port isn't on the Go port, so you can plug it into your PC, but you can also plug in things that you typically plug into your PC. For example, memory sticks, Ethernet adapters, sound cards, human interface devices and so forth. The Pluto, if you plug in a memory stick or a hard drive, it will auto mount all mass storage drives such as thumb drives and the supported file systems are EXT4, MS-DOS and FOWFET, basically FET32. How we do that?  In our case, it's MDEV. MDEV uses a configuration in e-file and in the e-file, we kind of instruct it if there is a new device appearing called SDA, for example, 0-execute-lib-mdev-automounder-shell script. This automounder-shell script will of course mount the file system, but besides mounting, it will also look inside that file system for certain naming convention. For example, if there is a file called runme0.sh, it will execute this as a shell script. If it's just runme0, it will run it as a binary file. You can have multiple of those and those are being executed based on their index. So runme0 runs before runme1. There's also another function that I just introduced with the GPIO keys slide. This is about safely unmounting this volume. So if the user hits the button, it will unmount this volume so you don't corrupt the file system. So how can you use this? So we use this, for example, to upgrade firmware. We just put the firmware on a flash drive, plug it in, and the runme will call the update script. But a lot of people use this to switch from the build root of S to, let's say, a full-blown ARM hard-flow to boot-to-root file system. You can do that by using the busybox-switch-root command. The switch-root command is nothing else than kind of a change-root. So you change-root into the new file system and execute the in-the-process of that new file system. This is really handy and pretty powerful. Managing hardware revisions and boot configurations. There are always hardware revisions, no matter what you do. But how can we handle those transparent to the user? Can there be a single firmware file who rules them all? Does the solution have image integrity protection? Or can it be fail-safe? And yes, there is such a thing, and it's called qimage.fit. Let's explain a little bit. So fit images are flattened image trees. These are basically multi-component images, and they support multiple configurations. Fit images also support FDT overlays, hashing and signatures, and they're also good for verified boot. But verified boot is not needed here, because this Pluto is as open as possible. Fit images use a device tree structure. On the right, you basically see a part of our U-boot script that kind of loads the whole thing. The fit image with an additional configuration. And then it starts booting. It says standard out serial echo boot. No, if the boot fails, it turns on the serial again and says it fails to boot and it enters a defue mode. So let's look a little bit at the Pluto.its. That's the source image file for that fit image. So fit images are structured like this. There is a root node over here. Then you have a kind of a description and a magic. And then you have an images node.  Here in this case, we have three different device trees for three different hardware versions. Ref A, Ref B, and Ref C. All these nodes have additional attributes here, type, architecture, whether things are compressed or not. They can have hashes and so forth. So the other thing is kind of the FPGA bit stream. That's kind of the configuration for the FPGA. So this one has a hash. It's not compressed. And then we have the Linux kernel image and our RAM disk. It kind of pulls this from root of a CPO.GZ. And it is Gzip compressed and also has an MD5 sum. And besides the image, these are kind of the inputs. We have these configurations over here, this configuration node. And in that configuration node, we have different configurations. Config 0, Config 1. Config 0 says we use kernel from 1, RAM disk 1, FPGA 1. Pluto currently only uses... So all hardware versions of Pluto use the same kernel, the same RAM disk, and the same FPGA. The only what's different is the device tree. So Ref A uses FTD 1, which is this. Ref B uses FTD 2. And there are actually two more nodes here which are omitted on here. So how do we handle hardware revisions? And that is kind of the poor man way of doing it. So each different hardware revision of Pluto has a slightly different bomb. So we have a voltage divider composed by these two registers. And for each Pluto ref, we kind of change R2 to be a different value. This results into a kind of a different voltage over here. And when the system starts, we read this ADC in UWOOD. Therefore, we have created this UWOOD command. We call it Pluto hardware ref. So we call Pluto hardware ref. And this is the function that it kind of does. It samples the ADC. And then it takes this value. And we have 100 millivolt increments. And we kind of check whether this value is within a certain range. And then we kind of get to an index. Then we use snprintf to print config at index. And we save this into the environmental variable fitconfig. So once we have executed this command, fitconfig is kind of set with config at one, for example, for refb. And then we just execute bootm command, fitload address config at fitconfig. And that's the whole magic. Works pretty well. So we're getting to the end of this presentation. A few people asked me whether is it working, making open hardware, open system. Yes, it is. We have shipped nearly 40,000 devices since the release in 2017. We have many, many users in education and academia. But there's another community which is like rapidly increasing. And that's the hem radio amateur community, which use the Bluetooth for satellite communication and all other crazy things. It has been widely adopted by the open source community. And there are many, many, many SDR integrations into all kind of different frameworks. The feedback that we get from the customer is very positive. And it just works. Some other comments I recently got was that it's very easy. This R&D Ethernet function is very easy to integrate it into a virtual machine. And of course, LibIO is very stable and cross-platform. Here are some links and good pointers. So if you want to learn more about the analog devices university engagements, here are some two links. There's the wiki documentation about the Pluto, good pointers. And of course, the source code can be found on our GitHub. And I also like to list three books on software-defined radio. If you got interested, this is very good reading. So thanks for your attention and let's open the Q&A session.


This 2016 Ram 3500 crew cab long box dual rear wheel Laramie is stock number 12196Z. We are here at Summit Automotive in Fond du Lac, Wisconsin. You're new and used heavy-duty truck headquarters. This 2016 Ram 3500 has the high output 6.7 liter Cummins diesel. It is paired up with the Eisen heavy-duty transmission. This truck has been fully-safetyed and inspected by our service shop as a fresh oil and filter change. All the fluids have been checked and topped off, and this truck is 100% ready to go. White pearl is the color. We shoot all of our videos in 1080p, 60 frames per second. So if you have HD capabilities on your computer, tablet, smart phone, or television, turn them on right now because it is definitely your best way to check out the quality and condition and options of the truck before seeing it in person. We do a full walk-around, and if you like the video and want to subscribe to our YouTube channel, in the lower right-hand part of the screen is a subscribe button. Click that, and then click the bell notifications. You'll get updates on the videos we do each and every day here at Summit Auto. This one comes with the polished aluminum 17-inch rims, and it has Nexon Rodion LT 23580R 17 tires on here. These tires look like they have about 60 to 70% of the tread left on them. Frame and underbody is exceptionally clean for being a 2016. Front fender is in excellent shape. I didn't see any major dents or dings on there. It has the projector lamp headlamps, the LED running lights, and the factory fog lights. Notice you do get the front bumper parking sensors. Front bumper is in nice shape. The only thing I saw is one tiny little ding by that sensor there, but nothing too bad. Chrome-trimmed grille, but that's why we do the videos. We want to make sure that we give the most accurate representation of the vehicle as possible, so when you get here, there's absolutely no surprises. The hood's in really nice shape, and it does have the clearance lights up top. Passengers side front fender looks really good. No major dents or dings on there. Passengers side rim, no major scuffs or scrapes. And as you go down this side of the truck, take note of how clean the body is, how reflective and mirror-like that paint is. We take these HD videos, so if you are far away or even if you're close by and just cannot make the trip down but you're still interested in purchasing the vehicle, you can see the truck, hear the truck, and have confidence in the vehicle that you're looking at before you even get here. So when you do get here, there's no surprises, and you can make a smart and informed buying decision from your own home or wherever you may be watching this video. Very clean down that side. I didn't see any dents, I didn't see any dings. The dually tub looks really good. I didn't see any major rock chips or anything. It does have the 3M plastic guard on there. Back rims are in excellent shape as well. Back tires have just as much tread as the front tires. And like I said before, the frame and underbody is in really nice shape. Very little to no corrosion. As all the remaining factory exhaust, and the underbody is in pretty nice shape. Just a little bit of dirt, but nothing too bad. Lower rockers look really good. It does come with the factory chrome step bars. Coming around to the back of the vehicle, that dually tub's in really nice shape. Rear bumpers in nice condition as well. No major dents or dings on there. It does have the backup parking sensors full towing package, which includes the receiver hitch 4 pin and 7 pin wiring. The tailgate is in excellent condition. This one comes with a Truxedo Low Pro soft roll up tonneau cover. And that is in really nice condition as well. This one also has the spray and bed liner. Fifth wheel and goose neck prep package. Has the 7 pin wiring back here, LED bed lighting. And this one does have the cargo cam up there, which allows you to take a look inside the bed while you're driving. Obviously you have to have the tonneau cover off, but as you come around this side of the truck, pretty nice. I did see a couple tiny little dings at the top of the box there, but not much you can do on these dually beds. It's really, really thick metal on here. And for full disclosure, this back rim is in excellent shape. Down the rest of the side of the truck looks really good. Doors are really nice. Has the entry and go system. These mirrors fold up like so. They're heated, have built in directional signals. Inside the Laramie package gives you the tan leather interior. There are no rips, there are no tears on the seats. They're in really nice shape. Memory driver seat, factory formats, auto headlamps, power windows, power locks, power mirrors, and these mirrors do power fold in. I always like showing both sides so that you know that both sides are working properly. We'll hop inside, turn the ignition on so we can check out the miles and the radio. You get the Laramie animation at the beginning there. And you can see that this truck has 33,467 miles. You do get the digital speedometer, temp, gain for your trailer brakes, compass, and range to empty. You can change those corners to read whatever you want. Instrument cluster is very nice and clean. Comes with the heated leather wrap steering wheel, cruise controls on the right, Bluetooth and information center controls on the left. And as always, they have the audio controls on the back. This one has the six speed ICEN heavy duty transmission with the optional tap shift. It has the 8.4 3C radio, AM FM and Sirius XM radio capabilities. You can see we're conveniently located right off Highway 41 in Fond du Lac, Wisconsin. You get AM FM and Sirius. You also have your heated and cooled seat buttons here. And you can check out your backup cam or you can check out that cargo cam just about any time you want. You have all your different climate controls here as well. Note that you do get the dual climate controls and where it's blowing in everything. Now, if you don't like using the controls up there, don't worry, you can use the more tactile buttons and knobs down here, including volume and tune controls for your radio. Turned-out four-wheel drive, factory brake controller, more heated and cooled seat buttons, as well as the heated steering wheel button, stability control, tow haul. That's for your factory exhaust brake, front and rear parking sensors, and a 115 volt, 150 watt plug-in. Your keyless entry with the remote start. That's in nice shape. Passenger side, floor mat and seat are in excellent condition as well. No rips or tears on there. Smells very clean inside this truck. I don't think it's ever been smoked in. You get the speakers in the ceiling, part of that Alpine premium sound system. Map lights, power sign, rear window button, and home leak buttons for your garage door security systems and lighting systems. 911 and assist buttons in that rear view mirror. And there's your Alpine premium sound badge. We'll take a quick look at the back seats and then we'll start it up and check out under the hood. Back seats are just as clean as the front seats. No rips or tears back here. It does have the latch child safety system for any child car seats you may have. Power sliding rear window with the built-in rear defrost. Seats are really nice. It does come with a load floor, which is nice. If you've got muddy boots or tools, put them on there. You're not going to wreck your nice leather seats. Or if you've got pets, put both sides down. They've got a nice flat place to lay. And then underneath there, you get storage. And under the floor mats, you get in-floor storage with removable bins for easy cleaning. You can put ice and drinks in there.  Seats fold down nicely. Child safety locks on the back doors, bottoms of the doors all look really good. And we'll start it up and take a look under the hood. Starts right up. No check engine lights or anything like that. I would personally like to thank you for checking out the video today. And hopefully from this HD video, you'll have been able to verify the cleanliness and condition of the vehicle inside and out. Under the hood, we have the 6.7 liter high output Cummins diesel. This truck has been fully safe and inspected by always-so-the-shot. It has a fresh oil and filter change. All the fluids have been checked and topped off. And this truck is 100% ready to go. There's your emissions sticker right there. And I would highly recommend this truck from a quality and condition standpoint. And to see more pictures of this truck or one of our other 450 new and used cars, trucks, SCVs, minivans, Wranglers, half-tons, three-quarter-tons, one-tons, you name it, we got it. Go to that website right there at www.SummitAuto.com. Full pictures and descriptions of every single vehicle from two locations all at SummitAuto.com. And if you'd like to check out more HD videos, you can go to YouTube.com slash SummitAuto. Remember to like, subscribe, and share on this video and all the videos that you see there. In fact, in a second, you'll see a link to subscribe to our YouTube channel. The upper left, the link to more Ram 3500 truck videos like this one on the upper right. Link to this vehicle on our website on the lower left and link to one of our latest YouTube videos on the lower right. Click those, check us out. And we're super excited to help you with this ultra clean 2016 Ram 3500 crew cab long box dual rear wheel Laramie in pearl white with a high output Cummins diesel in the ice and transmission. Thanks again for checking out the video.


All right, I guess we can get started. My name's Toby Ford. I'm from AT&T. And I'm Matt Skolson from Ericsson. We're going to talk today, or an extension of what we were talking at the last summit about, the last summit we introduced NFV. We're going to actually go the next step is talk about what we've done over the last six months in terms of evolving OpenStack to be able to support NFV. And then we're actually going to demonstrate an aspect of how to use it to achieve some level of HA underneath as one subset of an NFV solution. Just as an overview, this is the things we're going to go walk through. As I said, we're going to just talk to a little bit of the basics, try to be a little bit incremental to what I've been already talking about at the keynote or in the previous talks, and then go through some issues that we've had trying to bring new functions into OpenStack around solving for NFV problems. And then we're going to go through a demonstration. Again, for those that haven't heard this already, I'll try to be brief. And hopefully you haven't heard my story about this already. But recently I was playing golf, and then they paired me up with this guy who had just retired. And we were walking along, talking about what we do. And I was talking about the cloud. And he told me, oh, I live in the Washington, DC area. So this guy just recently retired. He had started a company 30 years ago supporting mainframe software. And he'd been very successful with the federal government with this mainframe software. So we got into it, and then he's saying, oh, yeah, the cloud. It's just like mainframes. It's a shared thing. It's all the same. It's just coming back around. And then I did not talk to him for the rest of the round. I was ignoring him. This really irked me, because for me, and when you're in Paris, you're supposed to talk like a revolutionary, I feel like the PC revolution and the Linux revolution and the open source sort of things that have happened since Linux have started have kind of broken this mainframe thing and has brought it almost to its knees. And it's almost gone. So that really irked me. And NFV is really an extension of that concept. It is taking what in the telco world is an equivalent to a mainframe, a vertically integrated box, something as simple as DNS, but done at huge scale. We needed to have a vendor provide DNS for us in a fully integrated solution that only scaled vertically, adding more processors, more line cards, et cetera. This is only one example. Obviously, many of the things that we do, from switches to routers to more sophisticated mobile systems, have been in telcos delivered this way. And obviously, there's a lot of shortcomings to this. It takes a long time to upgrade. The evolution cycle is very, very slow. 18, 24 months are short in our world. So extending this and evolving this has been very difficult. So we want something else. We want something akin to what we've gotten in the PC revolution, a marketplace, an ecosystem that is very extensive in terms of ISVs and startups and such. We want something like the Linux revolution where we can work together, especially on non-differentiated functionality, the sum of which is grown dramatically. When you think of all the telcos and what our needs are, we don't really have a lot that's going to be really unique. We want to make something that is open, extensible, transparent. And so we would much rather it be done in a virtual way, in a scale-out way, in a way that's easily extended. So. Sure. So I think I click it on. So this was also what we said in Atlanta. And I think one of the major reasons, I think, why I believe OpenStack is such a good thing for NFV is that it's truly multi-vendor. A lot of other virtualization management systems are having limitations on what stuff you can kind of plug into it. So really having a multi-vendor cloud ecosystem that you can plug in any equipment, any third-party services, any hypervisor, any guest, whatever it should say, really is the key tool for us. Because looking at the picture that Tobish showed, I think there is a multiple of different type of hardware vendors, et cetera, that needs to come into the same arena and play together. We also talked about a lot about the reliability. We are talking about five nines. We are talking about services like mobile telephony requiring five nines on the service level. Five nines is less than five minutes of downtime per year, including planned. That is quite hard requirements. These things we need to keep. We need to keep the SLAs on the service level. But of course, the implementation will be very, very different when you're talking about a cloud infrastructure. But we need to move these applications over to a cloud deployment environment. And we need to retain these characteristics. And I think a lot of the things that we are actually doing now is trying to figure out exactly how can we retain these characteristics on the service level. We also went into some of the examples in Atlanta talking about resource allocation, resource isolation, optimization. This is really a need. I mean, you need to be able to exclusively add cores to a specific VM or exclusively add network capacity to a specific VM. If you take a packet core application, for instance, that will actually require the whole IU capacity to that core in order to work in a good way. We talked about the networking. I think the networking is really an area where I think there is the biggest need, so to say, to improve and do additions. I think one thing with the network functions is that you need to be able to orchestrate the wide area network, not only the local area network within the data center. You need to be able to orchestrate the network that is also outside the data center. Real-time response, if something happens, interrupts the whole area around the virtual switch. Needs to be line rate to the VM. High availability, we talked about five nines. And five nines is really also, I mean, it's very much about fault mitigation, monitoring. A lot of these things that maybe it doesn't sound so much of high availability, but in our view, is the things that we really need to focus on. We need to reduce the risk of single point of failure. Then I think I was reading a lot of the journalists from when we had this panel yesterday, that I think there is a lot of good discussions now about upgrades and backup and restore. I think if you're looking on telecom, we should really have systems that there should never be a need for reinstall. There should be a good support for rolling upgrades, et cetera. Because we're talking about this five level of availability on the service level, we have to have these functions in place. So if we're then talking about a bit what we have actually been doing, since last VLON Tranking, that is really to make the VLON aware VMs to be able to isolate the network all the way to the VMs. We talked about VNF provisioning that is to be able to provide layer three resources to our virtual network functions. Optimized data path that is so that I have a virtual switch that can actually deliver line rate to the virtual machine. High availability. And I think here a lot of the high availability we are focusing on is, for instance, mitigation of failure and reusing the risk of a single port of failure. And that is also included, for instance, that you need to monitor the physical resources. And you need to combine the monitoring of virtual resources and physical resources and make sure that whatever happens, that you have the best possible view of what happened and how you can mitigate it in a very, very quick way. We are also working a lot on the assurance part. Because one thing that a telecom system, even if it's only deployed within one operator, is that a lot of these telecom applications will not have the same SLAs. They will have different SLAs. They may have different views on how to protect the data that is running in the application. That, for instance, means that we actually need to have complete multi-tenant. Multi-tenant in terms of how to handle resources, but also multi-tenant in terms of how to handle SLAs, how to handle trouble ticketing. We should be able to provide a trouble ticket per tenant. So I think here is also an area now where we are kind of putting a lot of emphasis on focusing also the multi-tenancy aspect. Because that will be needed even within one operator. Yeah, so I'm going to talk about one specific thing that Matt's brought up was VLAN Trunking. So this is a good example because it has as many of the facets of the problem space that we're dealing with in OpenStack around NFV. So VLAN Trunking is essential for one particular function, the session border controller gateway piece, which is in the IMS Core and how we manage SIP calls. So today, that piece of software requires direct network access and control over VLANs and Q&Q to be able to create an end-to-end separation for specific calls, which is required for a lot of the phone communications, this L2 separation for that. So that is a good example where today, an NFV or a VNF doesn't really respect the typical IT abstractions of who does what. Really, the OS should be dealing with this particular thing. But because of its past and it's just recently being ported over to this model, it doesn't do that. And it's going to take us a while to be able to do that. And obviously one part of the challenge in this one area is working with the VNF vendors to modify, to look more like traditional cloud. So that's obvious, that's one thing. But we have an interim period where that's not possible. So we, and we want to move quickly to implement solutions around this. We're deploying two enterprise-focused telephony systems today in OpenStack to try to make this work. We don't have time to wait. So we really needed this function in place. And really, it's essentially OpenStack managing OpenVSwitch to be able to expose what OpenVSwitch was already able to do is make a network device on a Linux box, be able to see all of VLANs and have the facility to trunk that. So it wasn't really that hard. And the Ericsson people had identified this as a key thing to make happen early on. So putting up sort of a blueprint of the history of the blueprint to just to show kind of our problems in two dimensions. One is really about what we're doing now is getting people aware of the NFV problem space and helping to promote it. And so Mots and I did a lot of work this way. Hopefully that helps. We've done a lot of work within the community. I spent a lot of time with Red Hat folks trying to convince them to help me to build up an NFV working group that was started thanks to Russell Bryant, very helpful work that he's done to bring together a group of about 40 different people to actually every week on IRC talk about NFV issues. So that's one angle of it. The other is specifically when we look at the timeline for this particular blueprint where the blueprint is saying, okay, we want VLAN trunking. You know, it's been a journey over the last 13 or so months from the point in time when the developer from Ericsson, Erick Mo actually submitted the blueprint to actually making it into the code base and into upstream vanilla. So it's been a pretty long journey. I won't go into the details, but it's indicative of something of a challenge that we have. There's the paradigm shift and the acceptance of sort of having to deal with these legacy systems and sort of an interim solution to solving them. That's one thing. But then also getting at a more fundamental problem with an open stack is just we need more help. We need more reviewers. We need more people familiar with networking and familiar with VNF in particular to help us. And so that's another aspect of it is bringing in and trying to get help from a broader spectrum of vendors and telcos to make this work. So this is typical of actually a lot of things and it's not only a VNF or an AV problem. It's also across all of open stack and something the foundation is trying to work on. So another sort of vector and trying to solve it we've been working on is trying to help the PTLs and augment them as much as possible to make it so that we increase the kind of flow of blueprints and specs to get to manifestation. So that's one part of it. Now, these are some of the examples that I talked about already of how we can help make this change. So pushing on the VNF vendors and working with the community. We felt like in the syndrome time that even more can be done. And this is one reason why we started the OPNFV effort is actually take the best of a standards body like Etsy and the best of open stack and put them together and create something new that actually would focus on NFV and in a practical way do allow us to create sort of a center of gravity, a group of people, some momentum that has some weight to push requirements into not just open stack but obviously open V switch and open daylight and DPTK and open data plane, these other things that are needed to make this work. And then also create sort of a test suite and integration model for putting all of them together and making them work. So this is obviously a broader problem than just open stack. So this is our attempt of even going down the road even further to make this more open stack like. And then hopefully in the next quarter or so we'll see actually certifications and sort of code come out of the OPNFV. Okay, now we are going to a demo and this is always interesting when you're trying to do it live actually here. So what we are doing, demo and this we have been working with the agency for a year or so. This is really, this is a control server of an IMS system called CECF. And this is about how do we actually do monitoring and how do we handle the compute failure that the whole host goes down and demonstrating some of the HF features that we are kind of doing. So take to kind of keep the service level up all the time. And we are using, so to say, the provisioning of the VNF we are using open stack. And we also are using as I said, a cloud manager. And as you can see here, we are defining, so to say, and I didn't talk about that in the beginning there, but of course affinity and anti-affinity is of course a very thing that is very important for this type of application and work loads. So in this case we have, so to say, and maybe the name system controller that is not, so to say, that is the controlling part of the applications and PL that is the traffical part of the application. So PL3, PL4 is handling the diameter signaling, PL5, PL6 is handling the traffic or the SIP signaling. And as you can see the system controllers is defined as one anti-infinity group and the traffic handling part as another one. So these are, this setup is running on standard HP blade servers. We are using as I said, a cloud manager for the orchestration. We are running, so to say, there is now I'm only showing the two VMs for the traffic handling part, the SIP signaling part. We have of course a lot of other, I mean, IMS is not only one application, there is a lot of them, maybe too many sometimes, but you have the subscriber register, you have a lot of other applications that is running on other VMs in the setup. We also, in this case, are using traffic loading tolls. We have roughly around 2,000 SIP subscribers registers, not all of them are of course making calls at the same time. But we are, so to say, establishing new SIP session at the rate of one per second. So these two VMs is handling one instance of this traffic handling part, the SIP signaling part. What is also maybe important to state that there is session replication between these two ones, but that is handled on the application level in this case. So it's not handling on the per VM level, it's handling on the application, so the application actually replicates the sessions all the time, so between these and there is a load sharing between them. So what we will demo here is to bring down one of the hosts where one of these VMs is running. What you will see here is that since the sessions were already replicated from start, so to say, more or less you will only kind of go activate the sessions on the standby side from kind of passive to active. So that means that there is kind of nothing will happen with the sessions that are already established and up and running. We will then create a new VM on a new host and you will also see that soon that that VM will start executing traffic and it will start the load sharing happen to that VM. And this will happen without any service interruption on the actual service. So this is the core control server of an IMS system. So this is what is handling voice, so say in an LTE system. This is a more detailed setup of all the hosts that are involved and the Infinity Group. As you can see, they are distributed. The SICK is the Cloud Infrastructure Controller, that's OpenStack, you have the two and the Infinity Groups for the controlling part of the application and the traffic handling part of the application and then you have the things like Horizon DNSs, HSS is the subscriber register system for IMS. And then there is another one for handling like the tools on the Goys that we are using. So are we ready then, Svettu? Yeah. So here you actually, if you remember the slides I was showing, you have the system controller, you have the four payload nodes so the traffic handling parts of the application. What you see here is the amount of SIP calls that is ongoing and you see there is a load sharing between these two and it's roughly around 130 calls per one. And as I said, all the sessions are replicated between these two application instances and of course not, as I said on application level, not on the VM level. So are we then prepared to kill one of the, so this is running downstairs in a booth. So this is, we couldn't bring it up all the up here. So this is, so I don't know if anyone can run down and check that we are actually rebooting it in real time. So after a while now you will start that it's kind of graceful, it takes it down. Hopefully now you saw that it stopped handling the traffic on that payload node and moves over all the traffic so now all the incoming SIP sessions are going to one of this VM and this application instance. And then that swapped to yellow and that means that it starts to evacuate the VM. So after roughly 45 seconds or something it will notice that the blade is dead or not responding. So it's just hoping that things are working. It's good fun, but I mean, when you're running live. Yeah, so this is actually, as I said, the demo is down in a booth and it's running live down there. So hopefully we'll start seeing some alarms popping up. So now it's evacuated in the VM and you've got an alarm for that one, I think, an SNMP trap. Yeah, and now it's gone completely red. That means that it's taking out, so it's, yep.  Another VM on the 11, there it comes. Still not handling traffic, but it's up. Yeah, so this is a VM and then it was spinning up the application instance. And after a while it will balance the traffic for both these. And as I said, this is a real IMS system and it's happening in real time. I don't know how long it takes before it's, but I think this is just giving you a bit of examples of what type of additional features, et cetera. Yeah, it's up. Good, worked. Thanks. So this was actually, as I said, I mean performing live and that's why we couldn't really completely control the timing. But during this whole period now, there was no traffic lost, I would say, because the sessions were replicated on application level. Of course, during a while, you had to take the double load on one of the application instances. So of course, during that time, you're of course very sensitive if that one fails as well. That's depending on how many instances you have, how secure you want to be. But this also shows that how can we implement this type of five-nines of availability. And this is of course, a mixture between things that we do on the application level and things that we do on the virtualization management level. And I think that is probably how it's going to be that some things we will actually not do on the virtualization management level because it's maybe too complex. Okay, so that was the demo piece. So we didn't have the complete cloud management solution, et cetera, in place, so this is why we only show in the SNMP, yeah. So, we also have, as I said, we're also showing a number of other things that we're doing and actually showing them as live demos. Another thing that we also have been working a lot with AT&T is what we call the Ericsson Virtual Switch, more or less providing line rate without really the need of an SRIV, so to say, without imposing hardware requirements. OpenStack live upgrade. Maybe I can take them. I will not be the expert in answering all the questions around them. But this is really, as I said, and this is, of course, one thing that I think it's really important for a lot of the network applications that is really line rate to the VM and, as I said, isolation of the network. So here, of course, you have the maintained VLAN tagging, 100% tenant separation, and you have the line rate to the VM. Live upgrade, this is showing, I would say, more of a type of spare wheel upgrade, so that you're moving one instance over to the next generation. And as I said, this is probably not the end solution of upgrade. I think there is needs for much, much more advanced upgrade. But this is shown down there. VNF's orchestration, this is what we're doing with the cloud management. This is really about a lot of the anti-affinity ruling. I mean, how do you create virtual network functions? How do you scale them? How do you decommission them? How do you actually run things that are across multiple data centers? Migration of VM, fault management, performance management, and all this, of course. And the cloud management should be, cloud management by itself should be high availability. Virtual enterprise gateway, that is to say, how do you can actually work with virtual CP? How do you can distribute them? How do you can handle virtual customer premises equipped? Easy VPN, it's about how you can provision VPNs between an open stack part and an open stack-based cloud and an enterprise site. I think this is, of course, something that I think a lot of companies are working with and a lot of companies needs because I think being able to provision VPNs in a dynamic and fast way, so not have to wait for three weeks before the VPN comes up, so I think this is a given need for a lot of operators who understand as well. The last thing that we are demo, which is a company we acquired of Sierra, which is a policy-governed platform as a service, that is a pass layer. And I think what is really, what we're trying to push here is, of course, the governance part of the pass layer, because if you start building this complex system and things start to move, you start to extend your system, it's like, how do you make sure that the characteristics you required actually are executed? And I think we will more and more see that we need a lot of advanced policies that we need a lot of advanced policy functionality in order for making these clouds that we are now doing to perform. So, Toby. Yeah, so I'll just close out with one last slide talking about in the next period of time, the things that we're focused on and where we need help. So IPv6 is in Juneau, a good portion of it is finally in the code base. There's a few gaps still left to resolve that, but obviously for us, in the mobility space, IPv6 is huge. We can't have as many phones as we have, billions of phones out there, or now with M2M and Internet of Things. Just heard this interesting fact. Just yesterday, we released the numbers for last quarter. It was the first time that the number of devices for Internet of Things that we sold was greater than the mobile devices that we have for people. So I think that's just a trend that'll continue to explode and obviously, this is an essential function for making that happen. The policy story that Matt's last left with is essential. Being able to guarantee certain characteristics like packets per second or some level of separation or authorization to do something. Many different realms of rules have to be applied to a system like this to make it deterministic and really do what we've contracted with customers to do. So this area needs a lot of work and I'm very hopeful that we're able to do something within the OpenStack community to do this as well as I'm very bullish about the acquisition of Epsera. I really believe that policy needs to happen a priori within this tools, it can't really be grafted on. The performance, as Matt's talked about with the enhanced or Ericsson vSwitch, any work around this area of increasing the throughput of network through a X86 host is key. So we're doing a lot of work in OpenVSwitch and testing out with Ericsson's vSwitch and then also working with SRRV and Intel trying to find a way to make it so that a host can do what we needed to do. This will be the key kind of boundary expanding work that we do to make this NFV work happen. Obviously, I believe that this isn't gonna work for the Tokos unless we have a diverse set of workloads running on it. From the back end IT systems to the NFVs, they all have to run on this, big data, whatever unused asset we have, we need to make it work but it has to be secure. We have to guarantee reservation and separation. So that's gonna be another area. And then I think the last two things are combined together. We will be deploying 150 or more OpenStack sites, separate distinct geographically different locations. In order to make that happen, we have to make OpenStack easy to deploy, easy to upgrade, easy to manage in a holistic way. So good works happened already with Keystone and with other areas like that where it's obvious, like Glance and such, where you don't wanna be having your images everywhere. You wanna have it deployed once and then it spreads out. Keystone, you don't wanna have authorization done all separate, it has to be in one place. Same thing will apply to the other areas. So these are, I think, six key areas that we'll be focusing on in the next period of time. All right, I think that's it. Any questions from the audience about this area? Feel free to use the mic in the front or the back. Hi. How much are you right now for services like VIMS, VEPC, just replacing physical machines with virtual machines and how much are you re-architecting those services to work better in the cloud? That's a very good question. So I mean, for the three major components of mobility, it's really just a porting of what had been in hardware and moving it over. Now, and I think the first initial deployments will be that kind of legacy. It's gonna take us a while to re-architect those types of systems to the fully cloud scale out model. Though, frankly, they did show up with a lot of this concept already embedded, so it's not so bad. But certainly, when it comes to managing load across many different devices, it had already been pretty good at doing that. When it comes to vertical scaling versus horizontal scaling, that's where work has to happen. So that's where the whole midget cattle come in. Yeah, and as most of the telecom application have been, as I said, have often good horizontal scaling on application level. And most of them are kind of plain Linux application. I think we have had examples of applications that are, for instance, have been relying on Linux kernel fixes. I think that is pretty hard, so to continue. So you more or less, you have to move the... I mean, there's two things you need to kind of virtualize a network function. One is, of course, that it becomes a pure Linux app. The other one, which I think has been a major challenge for us, is really to separate the management piece from management of infrastructure, management of our application. Because a lot of our applications, you have actually been managing the infrastructure for that application through the application. And I think that you need to separate the management. And I think that has been, I think, the major investment for a lot of applications changing the management structure. Yeah, exactly. I mean, we want one more contiguous orchestration across many VNFs and not one specific orchestration for each VNF. So that's a key concept. Yes. In our setups, we use Solometer, but you can talk to this. But we all use the telemetry in other parts, yeah. But you're pointing on a very, I think a challenge is that a telecom system really need a notification mechanism and not a polling mechanism. But I think that is how OpenStack is a good thing to do. All right, any more questions? Oh, yeah. Hi, my name is Salman. So the focus will be on the high availability. I'm wondering, are you looking also towards the mobile protocols to make it more resilient and more better because there are solutions available in that direction that allows you to make more better solution? Yes, I mean, I think in general, I think you can actually achieve a lot of good resilience, having good network protocols, so to say in between. And I think we talked about that I don't think the best way is to take the existing application as is and only move them and try to kind of do whatever we did to create this type of characteristics on the box. I think we need to use a lot of other tools. And for instance, resilience on network level by kind of using mobile protocols or whatever, so to say to achieve resilience. I think that is things that we are looking into, yes. Thank you. Yeah, so that's a very good question. So I mean, the question was about whether or not we see a unified sort of VNF manager or independent for each VNF having its own manager. So I mean, in my view, there will be some common infrastructure that we can reuse across all VNFs. So like autoscaling and templating of how it gets deployed and scaled, I think that's a good example of how we can use heat and its autoscaling mechanism as a sort of common denominator instead of relying on each VNF manager and its experience. Now, I think there's gonna be a balance for a while because the VNF managers that we use today have a lot of inherent knowledge of each VNF and its business logic and such. So it's probably gonna be a mixture. And you see, I think, quite a bit of integration with message queuing and those types of things to make it all work together. So I think there'll be a balance of the two at least at the beginning. Over time, though, where there's commonality you want it to be in one thing. And it's actually defined as a kind of a step two in OpenNFV to look on the VNF manager. But I think that the step one is really to focus on getting a agreed reference working platform on the infrastructure as a service layer as the first step. Exactly. All right, any more questions? I think this is good. Thank you.


Hey, this is Brett, and this 2018 Chevy Silverado 2500 Crew Cab Short Box LT1 is stock number 12939Z. I am here at Summit Automotive in Fondlac, Wisconsin, your new and used heavy-duty truck headquarters. This 2018 Chevy Silverado 2500 has the 6.6 liter Duramax diesel engine. It's the L5P engine, which puts out 445 horsepower. It's paired up with the Allison Heavy Duty 6-speed transmission. This truck has been fully-safetyed and inspected by our service shop as a fresh oil and filter change. All the fluids have been checked and topped off, and this truck is 100% ready to go. Really clean. I'm going to go all the way around inside underneath, start it up, and take a look under the hood in this video. Black clear coat is the color, and I shoot all my videos in 4K. So if you have HD capabilities on your computer, tablet, smartphone, or television, I invite you to turn them on right now because it is your best way to check out the quality, condition, options, and of course the cleanliness of the truck before seeing it in person. And if you like the video and how I do things here at Summit Auto, you can subscribe to my YouTube channel, and then click the bell notifications, you'll get updates on the videos I do each and every day here at Summit Automotive. This one comes with some really good looking 20 inch fuel painted and like anodized metal, it's actually probably painted in there too, but really, really good looking rims, especially with the red trim on the truck. No scuffs or scrapes on those, and it has Nitto Trail Grappler MT tires. These are LT32560R20s, and they have just about all the tread left on them. I'm guessing these rims and tires were put on recently. Frame and underbody is in really nice shape. This truck spent almost its entire life in Ohio. Clean title history, clean car facts, clean auto check, projector style headlamps, headlight lenses are nice and clear. You do get the painted front bumper, get the front bumper parking sensors, chrome trimmed grille, and this one has the cowl induction hood. This is a true cowl induction hood, I'll show you how that works in just a little bit. Didn't see any dents or dings on the hood, and the passenger side front fender is in very nice shape as well. No dents or dings, and this passenger side rim, no scuffs or scrapes. As you go down this side of this 2018 Chevy 2500, take note of how clean that body is, how reflective and mirror-like the paint is. I take these HD videos so if you are far away, or even if you're close by and you just cannot make the trip down, but you're still interested in purchasing the vehicle, you can see the truck, hear the truck, and have confidence in the vehicle that you're looking at before you even get here. So when you do get here, there's absolutely no surprises, and you can make a smart and informed buying decision from wherever you're at. And if this video helps you make that smart buying decision, let your salesmen know that you saw the video, that it was helpful, and that Brett sent you. Back room is in excellent shape, and once again, if you want to subscribe to my YouTube channel, I do videos like this every day in the upper right hand part of the screen, there's a link to subscribe. Back tires have just as much tread as the front tires, and the frame and underbody, other than just a little bit of surface rust, which is pretty common on these GMs, is in excellent shape, has all the remaining factory exhaust, so it hasn't been altered. And the underbody is in a really nice shape, not just a little bit of water drip right there. It does come with some painted step bars, lower rockers all look really good. This back, this passenger side box looks really good as well, it ain't seen any dents, it ain't seen any dings. Coming around to the back, the rear bumper is in excellent shape as well. You get the parking sensors, rear bumper step, and the full towing package of course, the receiver hitch four pin and seven pin wiring. The tailgate is in excellent condition as well, does have a locking tailgate, backup camera. I'm almost wondering if this is a midnight edition, I didn't really check the ad before I started the video, this might be a midnight edition with all the black bow ties and everything, does come with a gooseneck hitch, and seven pin wiring back here, looks like they had some chains lane back here. As you go down the driver's side just as clean as that passenger side, no dents or dings in the box, paint is really nice on this truck, back rim is in excellent shape. And the rest of this side doors and cab all look really really good, does have the telescopic tow mirrors, they do have a telescope out like so, and fold in like that, built in directional signals, LED side lights, inside the LT one package gives you the black cloth interior, there are no rips or tears on the seats, you get the 40-20-40 split bench seating in the front, power driver seat, weather tech floor mats throughout, auto headlamps turned out four wheel drive and factory brake controller, tilt, telescopic steering wheel, power windows, power locks, power mirrors, and you get the Z71 door trim on there. Black seats, just as clean as the front seats, no rips or tears back here, it does have the latch child safety system for any child car seats you may have, fixed glass rear window with the built in rear to frost, headliner is in really nice clean condition, and these seats fold up and you get that weather tech floor mat back here, which keeps your carpeting looking good. This truck does have side curtain airbags in it, and the bottoms of the doors all look really, really good. We'll hop inside, check out the miles, the radio, and everything that this truck has to offer on the interior. You can see that this one has 43,574 miles, you do get the digital speedometer and instrument cluster there, compass display as well, and the Z71 instrument cluster too. Comes with the leather wrapped steering wheel, Bluetooth and information center controls on the right, cruise controls on the left, and it does have audio controls on the back of the steering wheel. The Allison six speed heavy duty transmission with the optional tap shift, and then this one does have the Chevy MyLink system, you get the MyLink radio, the factory navigation system, there's highway 41, which we are on, does have projection manager, you can project your cell phone to the screen via Android Auto or Apple CarPlay, CD player, dual climate controls, down here is your stability control, that's for your cargo lamps, that's also how you turn on your LED side lights, parking sensors, downhills, discontrol on your factory brake controller, I'm going to turn the light on so we can see this, it does have 110 volt, 150 watt plug-in right there too, and a 12 volt power point. Passenger side format and seat are in excellent condition, no rips or tears on there, smells very clean inside this truck, and once again that headliner is in very nice clean condition. You get map lights up there and on-star and SOS buttons in the rear view mirror. We'll start it up and take a look under the hood. Starts right up, no check engine lights or anything like that. I would personally like to thank you for checking out the video today, there are those LED side lights there extremely bright, and hopefully from this HD video you'll been able to verify the quality and condition of this truck all the way around, project the lamp headlamps, factory fog lights, they're all working nicely. Take a look at that Fabtech lift there as well. Clearance lights are working well up there too, and under the hood we have the 6.6 liter Duramax diesel engine, L5P engine, 445 horsepower, engine base very clean runs very smooth, and once again this truck has been fully safety and inspected by our service shop, has a fresh oil and filter change, all the fluids have been checked and topped off, and this truck is 100% ready to go, there is your mission sticker, that coal induction hood, the air comes in the front there, comes down to the side, right into the air intake, and this truck's 100% ready to go like new tires, really good looking rims, super clean on the outside and inside, and I would highly recommend this truck to make quality and condition standpoint, and to see more pictures of this truck or one of our other 450 new and used cars, trucks, SUVs, minivans, Wranglers, half tons, three quarter tons, one tons, you name it, we got to go to that website right there summitauto.com, full pictures and descriptions of every single vehicle from two locations all at summitauto.com, and if you'd like to check out more HD videos you can go to youtube.com slash summitauto, remember to like, subscribe, and share on this video and all the videos that you see there, click the bell notifications, you'll get updates on the videos I do each and every day here at Summit Automotive, in fact in a second you'll see a link to subscribe to my YouTube channel on the upper left, link to more Chevy 2500 truck videos like this on the upper right, link to this vehicle on our website on the lower left, and a link to one of our latest YouTube videos in the lower right, click those, check us out, and we're super excited to help you with this ultra clean 2018 Chevy Silverado 2500 Crew Cab Short Box LT1 in black clear coat, thanks again for checking out the video, remember to like, subscribe, and share on my YouTube channel, I really appreciate it, thanks again.


Today is the actual activation ceremony for First Law Enforcement Battalion. It activated on the 15th of May. Today is just the actual ceremony for standing up on First Law Enforcement Battalion. First Marine Expeditionary Force aboard Marine Corps Base at Pendleton welcomed First Law Enforcement Battalion during its activation ceremony June 1st. The mission of the First Law Enforcement Battalion is to provide the Marine Air Ground Task Force Commander with a force to conduct law and order operations and policing operations. The unit, formerly known as First Military Police Battalion, dates back to World War II. Reporting from Kent Pendleton, California, I'm Corporal Joshua Young.


Hi, it's Flare. The new version 0.2.0 of Streamerbot is out on the main release channel now. It's got some really huge changes that make it more powerful and easier to use than ever. There's more to cover than I can do in one video, but I want to go in-depth into the biggest and most significant change and also highlight a few of my favorite smaller updates as well. By far the biggest change is the new trigger system. This is a really fundamental change in how Streamerbot works and opens up a whole new set of possibilities. The gist of the change is that now instead of having actions be directly tied to specific commands or broadcasting software events or streaming platform events, there's a middleman called the trigger that we use to connect those events to the actions. Sound like pretty much the same thing? Well, in a lot of simple use cases, they are ultimately the same thing. A channel point reward is redeemed and an action runs. Someone subscribes and another action runs. To your users and chat, it won't really make that much of a difference, but it affects the day-to-day operation of Streamerbot quite significantly. In the background, this change turned the relationship between actions and events from a one-to-many relationship into a many-to-many relationship. What does this mean? Previously, you could assign the same action to several events at the same time. Maybe a chat command and a voice command and a channel point redemption all fire the same action, but if you wanted to have one event fire more than one action, you had to build a parent action that would then fire all the other actions. Essentially, an action could be assigned to many events, but an event could only be assigned to one action. With the new system, if you want a command to trigger six different actions, you can just do it. Before you get worried about having to go in and set up triggers for everything you've already built, I'll assure you that the update process will handle this for you. I have over 500 actions assigned to all sorts of different events and commands, and the triggers were created successfully for me with no problems. That being said, how do we set up a new trigger in this version? Well, it's a lot like adding a subaction to an action. You'll see now on the action tab that each action has a triggers section that you can add to in the top right, and you can add new triggers by right clicking and choosing from the menu. If you choose core commands command triggered, you can tie the action to an existing command. Another new and wonderful feature added in this update is that right here, you'll also see an add command button. Yes, you can add a new command directly from the actions tab, set up the command like you normally would have, and then you can save and add the trigger. Similarly, if you want to assign an action to some sort of event, you can just navigate to that menu, find the event in question, and then add details necessary for each event. In the case of cheers or donations or something like that, you may be asked for a min and max range. So you can set up a trigger for five bits and another for all 100, or for donations below $10, one for donations above $10 and so on and so forth. You may notice a little question mark above the triggers. If you click this, you can explore a list of all the triggers that have been set up and which action each one triggers. This menu isn't particularly useful day to day, but it can certainly help a lot when you're trying to figure out what else might be tied to a particular trigger already. One last thing about triggers that makes life easier when building and testing new actions in Streamerbot is that you can right click on a trigger that you have set up and choose test trigger, allowing you a simple way to test an entire action. You can even add a test trigger and assign specific values to any variables you wish to be passed in when you test. It's really, really helpful. So the switch to triggers is really the biggest change to day to day life using Streamerbot and it takes the most time to explain, but it's definitely not the only quality of life improvement that was made. Do you use global variables at all in your actions and wish they were a bit easier to manage? Well, you got it. First of all, you can now access global variables simply by adding a till day character before and after it, similar to how you can access existing arguments with the percent sign. Previously, you would have had to add a whole get global variable sub-action to fetch the value where you establish some argument name to store the value in, and then you reference that argument in your message or other sub-actions. Now you can skip that first part entirely. I'll probably make a short video about this on its own in the future, but feel free to leave a comment if you want to know more about how to do this if you have any other questions. All right, now take a look at the icons at the top of Streamerbot above the tabs. The rightmost one is labeled variables. When you click it, you get the variable viewer. You can browse all the persisted and non-persistent variables, including any user-specific variable. You can also click into any of these variables and adjust either the variable name or the value. So this is a really big quality of life improvement when you're building actions that use a lot of global variables and you want to see the state of each of those variables while you're testing. Speaking of testing, one of the main ways that I've generally tested stuff when building new actions in Streamerbot is simply by assigning a command to my action that I'm building and then opening chat either through OBS or in a browser window and typing out the command that way. Now there's no need to even open a browser window for this. You can just click the chat icon next to the variable viewer and it'll open an inline chat interface where you can monitor chat and type up commands directly. It's worth mentioning that this chat interface is also capable of monitoring and sending chat to and from both Twitch and YouTube simultaneously, which might be really useful if you're a multi-streamer. What's more, if you go into settings on this chat window, set up a quick action bar of up to five actions you can fire by hovering over chat message and then clicking the little one through five. These actions will have access to a number of variables based on the chat message hovered, including information about the message itself, things like emotes were used in the message, whether bits are given, whether it's a reply, the color of the chatter, etc. And information about the user, like whether they're a subscriber, basic stuff like their username and display name. You could use these quick bar actions as a way to give people a shout out easily, maybe copy a message to be used in some fun way, a la butt's bot, or maybe just fire a hug command or something like that. I'm still working out how best to leverage this feature, but it's really cool that it's even available. Another small but wonderful new feature is the ability to have your bot reply to commands in chat instead of just sending a new chat message. So someone could type their exclamation hug command, and instead of just spitting out a random message in chat, maybe even 10 messages later after the command, you can now actually leverage Twitch's threading feature and reply to the original message where the command was done. To do this, you just use the twitch reply to message subaction instead of the twitch send message to channel subaction. For a normal command or chat coming in through the twitch chat message event, you want to add percent sign msg id percent sign and then reply id. This way twitch knows which message you're replying. If you have a message id saved from some other means, you can also pass that in. These are the big things that I use pretty much every day since I've been running the alpha, but there's so much more too. VTube Studio is now a supported integration as well as crowd control and Algado wavelength. The YouTube integration now allows the use of a bot account, which hype chat is now supported if that's of interest to you as well. Import and export functions in Streamerbot have also been up. I should mention that old Streamerbot imports will still work in the new version, but new exports from Streamerbot 0.2.0 and later will not work in the older version. Myriad of other small changes, fixes, and new features have been added as well. I'll put a link to the full change logs in the description. Let me know in the comments what your favorite change was in this version or if you have any questions about some of the new features, I'd love to hear your feedback. For now, check out this other Streamerbot tutorial and learn about cues.