<div class="row">
    <div class="col-xs-12 v2-sub-page">

        <h2>NimBLE - Mynewt's Bluetooth 4.2 compliant stack </h2>

        <p>
        NimBLE is a complete Bluetooth Low Energy 4.2 stack featuring source code for both host and controller subsystems. You can choose to run NimBLE as
        </p>

        <ul>
           <li> a complete stack in a single processor</li>
           <li> host only</li>
           <li> controller only</li>
           <li> host and controller in separate processors on a board</li>
        </ul>

        <p>
        The standardized Host Controller Interface (HCI) allows you to mix and match Mynewt’s host or controller portion with another vendor’s controller or host implementation respectively, to suit your product hardware and application. As an example, you may run the NimBLE controller with BlueZ, the Linux Bluetooth host protocol stack. As a reverse example you could choose to run NimBLE's host with a chip vendor's controller that supports HCI over UART transport.
        </p>

        <h3>Features</h3>
        <ul>
          <li>LE Privacy 1.2 </li>
          <li>Security Manager (SM) with support for LE Legacy Pairing (Just Works, Numeric Comparison, Passkey Entry, OOB), LE Secure Connections, Transport Specific Key Distribution</li>
          <li>LE Data Length Extension</li>
          <li>Concurrent multiple roles (master(central)/slave(peripheral), server/client)</li>
          <li>Simultaneous advertising and scanning</li>
          <li>Low Duty Cycle Directed Advertising</li>
          <li>Connection parameters request procedure</li>
          <li>LE Ping</li>
          <li>32 bit UUIS</li>
          <li>L2CAP Connection Oriented Channels</li>
          <li>Full GATT Server, Client, and all sub-procedures</li>
          <li>Host Controller Interface (HCI) between the host and controller either through software API or by UART hardware connection</li>
        </ul>

        <h3>Profile and Service support</h3>
        <ul>
          <li>Alert Notification Profile and Service(ANS)</li>
          <li>Immediate Alert Service (IAS)</li>
          <li>Link Loss Profile and Service</li>
          <li>Transmit Power Service</li>
        </ul>

        <h3>Memory sizing</h3>

        <p>
        The recommended memory size for running Mynewt OS with NimBLE is 64 kB of RAM and 512 kB of Flash. This allows the application developer to build an image for a product with ample space for application data and logic, security capabilities such as secure bootloader, and operational utilities such as detailed logs and statistics.
        </p>

        <p>
        While the recommendations are for higher amounts of memory, Mynewt OS with NimBLE can be optimized to operate with 32 kB of RAM and 256 kB of Flash.
        </p>

        <uL>
          <li> Core OS kernel: <1 kB of RAM, <6 kB of Flash </li>
          <li> NimBLE Stack (including both peripheral and central roles, legacy pairing): 4.5 kB of RAM, 69 kB of Flash </li>
          <li> BLE peripheral application using Mynewt OS, NimBLE with security: 15 kB of RAM, 99 kB of Flash </li>
        </ul>


        <h3>Role configuration</h3>

        <p>
        NimBLE gives you tremendous flexibility to meet your application and device requirements. It has been shown to work with much higher limits when compared to other implementations such as Nordic's SoftDevice or Intel's Zephyr:
        </p>

        <ul>
          <li>Up to 32 concurrent connections as a Central which is 4x what is allowed on Nordic's SoftDevice/li>
          <li>Up to 32 concurrent connections as a Peripheral (32x what is allowed on Nordic's SoftDevice</li>
          <li>Up to 32 concurrent connections in any combination of Central and Peripheral with Observer and Broadcaster roles running simultaneously. In comparison, Nordic's SoftDevice allows 3 connections as a Central and 1 connection as a Peripheral while simultaneously running Observer and Broadcaster</li>
          <li>Ability for a peripheral to connect to multiple centrals (as opposed to only 1 central allowed on Nordic's SoftDevice)</li>
          <li>Flexibility to configure the scheduler to allow for larger data bursts when connected to a large number of peripherals</li>
        </ul>

        <h3>System configuration</h3>

        <p>
        NimBLE allows the application developer to configure the system to extract the most suitable performance. Whether it is getting the most number of concurrent connections or getting a high throughput or ensuring low latencies for data bursts to several peripherals, NimBLE offers plenty of options. Of course, any changes to the default configuration has implications on code size, runtime RAM usage etc., a glimpse of which is shown below.
        </p>

        <table style="width:100%">
          <tr>
            <th>Subsystem</th>
            <th>Examples of Configuration Options</th>
            <th>Default(kB)</th>
            <th>Element Size(kB)</th>
            <th>Default Size(kB)</th>
            <th>Size for x # of connections</th>
          </tr>
          <tr>
            <th rowspan="4">Host</th>
            <td>Max. number of config descriptors</td>
            <td>1</td>
            <td>4</td>
            <td>4</td>
            <td>(x+1)*3</td>
          </tr>
          <tr>
            <td>Max. number of attributes in a single GATT Reliable Write procedure</td>
            <td>36</td>
            <td>32</td>
            <td>1152</td>
            <td>Independent</td>
          </tr>
          <tr>
            <td>Max. number of concurrent connections</td>
            <td>1</td>
            <td>80</td>
            <td>80</td>
            <td>x*80</td>
          </tr>
          <tr>
            <td>...and several more. Full system configuration is specified in /net/nimble/host/syscfg.yml with sensible defaults. </td>
          </tr>
          <tr>
            <th rowspan="4">Controller</th>
            <td>Whitelist size</td>
            <td>8</td>
            <td>8</td>
            <td>64</td>
            <td>Independent</td>
          </tr>
          <tr>
            <td>RNG buffer size</td>
            <td>32</td>
            <td>1</td>
            <td>32</td>
            <td>Independent</td>
          </tr>
          <tr>
            <td>Max. number of concurrent connections</td>
            <td>1</td>
            <td>416</td>
            <td>416</td>
            <td>x*416</td>
          </tr>
          <tr>
            <td>...and several more. Full system configuration is specified in /net/nimble/controller/syscfg.yml with sensible defaults.</td>
          </tr>
        </table>

    </div>
</div>