【ember zigbee】第五章：ug103-03-Application Development Fundamentals: Design Choices 学习笔记(上)

写在前面

• 索引
  • 【ember zigbee】序章:协议栈相关文档学习笔记

1. 背景

  Silicon Labs is developing products designed to meet the demands of customers as we move to an ever-connected world of devices in the home, what is often referred to as the IoT (Internet of Things). At a high level the goals of IoT for Silicon Labs are to:

• Connect all the devices in the home with best-in-class networking, whether with zigbee PRO, Thread, Bluetooth Smart, or other emerging standards.
• Leverage the company’s expertise in energy-friendly microcontrollers.
• Enhance established low-power, mixed-signal chips.
• Enable cloud services and connectivity to smartphones and tablets that promote ease of use and a common user experience for customers.
  
  

  Achieving all of these goals will increase adoption rates and user acceptance for IoT devices in the Connected Home.
  As the range of options available to the application designer increases, the impact of early design choices also increases. This document describes the application design process in terms of major decisions that must be made about how to architect a wireless networking solution. Basic design choices include:

• Which Silicon Labs wireless technology to use
• Whether to use an SoC (system-on-chip) design or an NCP (network coprocessor) design
• If using the NCP model, how to select compatible NCP and host applications
  
  

  Design choices when developing a zigbee solution include:

• How to create the network (form, join, or leave)
• What security models will be used
• What kind of routing optimizations to employ in the network
• How to deliver messages through the network
  
  

  Once you have considered these choices, you can begin implementing the system design.

• ps:背景这类的没啥好讲的。

2、设计方案的选择

   Before beginning a wireless design with Silicon Labs’ wireless microcontrollers, you should first consider which of the available networking technologies would be most appropriate for your project. Once you’ve decided on the networking protocol you want to use for your design, consider whether your product will fit best into a System-on-Chip (SOC) paradigm or a Network Coprocessor (NCP) paradigm and, for the NCP, what kind of serial communication to use for controlling the coprocessor.

• 在开始使用Silicon Labs的无线微控制器进行无线设计之前，您应首先考虑哪种可用的网络技术最适合您的项目。 一旦确定了要用于设计的网络协议，请考虑您的产品是否最适合片上系统（SOC）范例或网络协处理器（NCP）范例，对于NCP来说，需要考虑用什么样的串行通信协议来与之通信。

2.1 应该使用哪种无线协议

   Silicon Labs offers the following stacks for development on the Wireless Gecko family:

• Silicon Labs Flex SDK, including the IEEE 802.15.4-based “Connect” stack (described in UG103.12: Application Development Fundamentals: Silicon Labs Connect) for multi-hop “star” network topologies, and the Radio Abstraction Interface Library (RAIL) for truly proprietary designs with custom RF configurations.
• EmberZNet, a zigbee PRO-based mesh networking stack, described in detail in UG103.2: Application Development Fundamentals: Zigbee.
• Silicon Labs Thread, a Thread 1.1-based IPv6 mesh networking stack, described in detail in UG103.11: Application Development Fundamentals: Thread.
• Silicon Labs Bluetooth SDK, a Bluetooth 2.3-based networking stack, described in detail in UG103.14: Application Development Fundamentals: Bluetooth Smart Technology.

   After familiarizing yourself with the details of these protocols, your choice among them will likely depending on your needs for standards compliance, networking topology, interoperability, frequency range, and message throughput.

• Silicon Labs在Wireless Gecko系列上提供以下用于开发的堆栈：
  • Silicon Labs Flex SDK，包括用于多跳“星形”网络拓扑的基于IEEE 802.15.4的“连接”堆栈（在UG103.12：应用开发基础：Silicon Labs Connect中描述）和无线电抽象接口库（RAIL） ）用于具有定制RF配置的真正专有设计。
  • EmberZNet，一个基于zigbee PRO的网状网络堆栈，在UG103.2：Application Development Fundamentals：Zigbee中有详细描述。
  • Silicon Labs Thread，一个基于Thread 1.1的IPv6网状网络堆栈，在UG103.11：Application Development Fundamentals：Thread中有详细描述。
  • Silicon Labs蓝牙SDK是一种基于蓝牙2.3的网络堆栈，在UG103.14：应用程序开发基础：蓝牙智能技术中有详细描述。
• 熟悉这些协议的详细信息后，您可能会根据自己对标准合规性，网络拓扑，互操作性，频率范围和消息吞吐量的需求进行选择。
• ps: 对于zigbee来说，我们关注的是 EmberZNet这个由silicon提供的zigbee协议栈。

2.2 SoC or NCP?

   Regardless of whether or not you use an application framework for the design, the choice of the design paradigm─either the SoC (system-on-chip) model or the NCP (serial network coprocessor) model─is a crucial one. It dictates the requirements and constraints of both the software and the hardware. This choice governs where the application resides relative to the core stack functionality. In the SoC model the entire system (stack and application) resides on a single chip, whereas in the NCP model the stack processing is done in a separate “coprocessor” that interacts with the application’s own microcontroller through an external serial interface.
   The following figure illustrates the various components of the stack and application and how they are organized relative to the SoC or NCP architecture model.

• 无论您是否使用应用程序框架进行设计，设计范例（SoC（片上系统）模型或NCP（串行网络协处理器）模型）的选择都是至关重要的。 它规定了软件和硬件的要求和约束。 此选择控制应用程序相对于核心堆栈功能所在的位置。 在SoC模型中，整个系统（堆栈和应用程序）驻留在单个芯片上，而在NCP模型中，堆栈处理在单独的“协处理器”中完成，该协处理器通过外部串行接口与应用程序自己的微控制器交互。
• 下图说明了堆栈和应用程序的各种组件以及它们如何相对于SoC或NCP体系结构模型进行组织。
  

   While the choice between architectures is not to be made lightly, the application framework masks the differences to some degree, simplifying a change from one architecture to another when necessary, or supporting a mix of architectures for different products.

• 虽然架构之间的选择不能轻易做出，但应用程序框架在某种程度上掩盖了这些差异，在必要时简化了从一个架构到另一个架构的更改，或支持不同产品的混合架构。

2.2.1 System-on-Chip Approach

   In the SoC approach, a single chip, such as one of the ICs in the Wireless Gecko (EFR32™) portfolio, provides all stack functionality (including integrated flash, RAM, and RF transceiver) as well as the application-layer components (application profiles, clusters, attribute management, and stack interactions). Stack functionality is implemented as pre-compiled library files, which you then must link with, along with your own application-related code, during the final build process to produce a single, monolithic binary image comprising everything needed for a completely functional wireless application. The application framework, although supplied by Silicon Labs, is considered part of the Application Layer.
   Note: While a bootloader is typically used in deployed wireless networking devices, that bootloader firmware is not part of this monolithic binary image. However, Silicon Labs does provide post-build tools that can be used to further combine both the application firmware and the stack firmware into a single HEX record file for ease of distribution and manufacturing. For more information about these software utilities for EmberZNet PRO applications, please consult document UG107: EM3x Utilities Guide, UG162: Simplicity Commander Reference Guide, and document UG103.6: Application Development Fundamentals: Bootloading.

• 在SoC方法中，单个芯片（如Wireless Gecko（EFR32™）产品组合中的一个IC）提供所有堆栈功能（包括集成闪存，RAM和RF收发器）以及应用层组件（应用）配置文件，集群，属性管理和堆栈交互）。堆栈功能是作为预编译的库文件实现的，然后您必须在最终构建过程中与您自己的应用程序相关的代码链接，以生成包含完整功能无线应用程序所需的所有内容的二进制文件(烧录文件)。应用程序框架虽然由Silicon Labs提供，但仍被视为应用程序层的一部分。
• 注意：虽然引导加载程序通常用于已部署的无线网络设备，但该引导加载程序固件不是此单片二进制映像的一部分。但是，Silicon Labs确实提供了构建后工具，可用于将应用程序固件和堆栈固件进一步组合到单个HEX记录文件中，以便于分发和制造。有关EmberZNet PRO应用程序的这些软件实用程序的更多信息，请参阅文档UG107：EM3x实用程序指南，UG162：Simplicity Commander参考指南和文档UG103.6：应用程序开发基础知识：引导加载。

  In the SoC approach to development, the application, including the application framework, is co-resident with the stack. The application calls APIs (application programming interface functions) provided by the stack libraries, and the stack triggers handler functions implemented by the application code. When the application framework is used for the application design, the framework handles calling these APIs and implementing the necessary handler functions, then wraps these in higher level APIs and application callbacks to simplify the design process and help ensure protocol compliance.
  Because the SoC model requires only a single chip, compared to the NCP model and legacy design architectures that require multiple ICs, the SoC model has lower power consumption, lower BOM (bill of materials) cost, and smaller possible layouts. Also, tighter integration with the stack software and radio hardware can be achieved when everything resides on a single chip, allowing for more precise and timely control over application behaviors correlated to stack activity.

• 在SoC开发方法中，应用程序（包括应用程序框架）与堆栈共存。应用程序调用堆栈库提供的API（应用程序编程接口函数），并且堆栈触发应用程序代码实现的处理程序函数。当应用程序框架用于应用程序设计时，框架会处理调用这些API并实现必要的处理程序函数，然后将它们包含在更高级别的API和应用程序回调中，以简化设计过程并帮助确保协议合规性。
• 由于SoC模型仅需要单个芯片，因此与需要多个IC的NCP模型和传统设计架构相比，SoC模型具有更低的功耗，更低的BOM（物料清单）成本以及更小的可能布局。此外，当所有内容都驻留在单个芯片上时，可以实现与堆栈软件和无线电硬件的更紧密集成，从而允许更精确和及时地控制与堆栈活动相关的应用程序行为。

  However, once you have committed to an SoC model, you are bound by the constraints of the available offerings in that SoC family. These include the following:

• Flash and RAM memory constraints
• Toolchain constraints, such as the requirement to use IAR Embedded Workbench for zigbee- and Thread-based SoCs
• HAL constraints, such as limited amount of peripherals of a certain type, or lack of a specialized peripheral that may be integral to your hardware design
• Timing constraints based on having to share a CPU with the stack, which has its own set of requirements in order to maintain IEEE 802.15.4 and protocol compliance

If any of these constraints are too much of a deterrent, the NCP model may be a more attractive alternative.

• 但是，一旦决定使用SoC模型，您就会受到该SoC系列中可用产品的限制。 这些包括以下内容：
  • 闪存和RAM内存限制
  • 工具链约束，例如对基于zigbee和基于线程的SoC使用IAR Embedded Workbench的要求
  • HAL约束，例如某种类型的外围设备数量有限，或缺少可能与硬件设计不可或缺的专用外设
  • 基于必须与堆栈共享CPU的时序约束，对应用的时序有一定要求，以便维持IEEE 802.15.4和协议合规性
  • 如果这些限制中的任何一个具有太大的威慑力，那么NCP模型可能是更具吸引力的替代方案。

2.2.2 NCP Approach with a Serial Protocol

  Note: This section does not pertain to the Bluetooth SoC or NCP models. For more information, consult AN1042: Using the Silicon Labs Bluetooth® Stack in Network Co-Processor Mode and UG136: Silicon Labs Bluetooth® C Application Developer’s Guide.
  In the NCP approach, a Silicon Labs chip with integrated flash, RAM, and RF transceiver runs most stack functions on its own through pre-loaded coprocessor firmware with runtime configurability, then uses a serial interface such as Serial Peripheral Interface (SPI) or Universal Asynchronous Receiver/Transmitter (UART) to communicate with a second device, known as the “host” processor, on which the application layer functionality is “hosted” separately from the core stack components. The NCP may be a special integrated circuit designed with limited I/O and reduced functionality for the express purpose of acting as a coprocessor or it may be a fully-featured microcontroller that happens to have the coprocessor firmware loaded onto it to make it behave as an NCP.
  To facilitate communication between the application’s host and the stack’s NCP, Silicon Labs provides two serial command sets. The first, known as EZSP (EmberZNet Serial Protocol), is used when developing zigbee solutions (see document UG100: EZSP Reference Guide, for more information about EZSP.) The second, known as Thread Management Serial Protocol (TMSP), is used when developing Thread solutions. An NCP solution is also available with the Silicon Labs Connect stack found in the Silicon Labs Flex SDK for proprietary development.
  EZSP, which operates either synchronously over SPI or asynchronously over UART (with or without flow control), mimics the EmberZNet PRO API with EZSP-specific command frames (which may sometimes differ slightly from their SoC-based counterparts in EmberZNet) and the EmberZNet-related handler functions with callback response frames. Silicon Labs provides EZSP driver source code that abstracts these serial commands and responses into a set of APIs and handler functions similar to those used in the SoC model. When an application framework is used to implement the application layer, it takes care of calling the necessary API functions and implementing the required handler functions, allowing the designer to focus on higher level application processing with client APIs and framework callbacks.

• 注意：本节不适用于蓝牙SoC或NCP型号。有关更多信息，请参阅AN1042：在网络协处理器模式下使用SiliconLabsBluetooth®堆栈和UG136：SiliconLabsBluetooth®C应用程序开发人员指南。
• 在NCP方法中，带有集成闪存，RAM和RF收发器的Silicon Labs芯片通过预先加载的协处理器固件自行运行大多数堆栈功能，并具有运行时可配置性，然后使用串行接口，如串行外设接口（SPI）或通用异步接收器/发送器（UART）与第二个设备（称为“主机”处理器）通信，其中应用层功能与核心堆栈组件分开“托管”。 NCP可能是一种特殊的集成电路，其设计具有有限的I / O和减少的功能，用于充当协处理器的明确目的，或者它可能是一个功能齐全的微控制器，恰好将协处理器固件加载到其上，使其表现为NCP。
• 为了方便应用程序主机与堆栈NCP之间的通信，Silicon Labs提供了两个串行命令集。第一种称为EZSP（EmberZNet串行协议），用于开发zigbee解决方案（有关EZSP的更多信息，请参阅文档UG100：EZSP参考指南。）第二种称为线程管理串行协议（TMSP），用于开发Thread解决方案。 Silicon Labs Flex SDK中的Silicon Labs Connect堆栈还提供NCP解决方案，用于专有开发。
• EZSP可通过SPI同步运行或通过UART异步运行（带或不带流量控制），模拟EmberZNet PRO API和EZSP特定的命令帧（有时可能与EmberZNet中基于SoC的对应物略有不同）和EmberZNet-相关的处理函数与回调响应帧。 Silicon Labs提供EZSP驱动程序源代码，将这些串行命令和响应抽象为一组API和处理程序函数，类似于SoC模型中使用的那些。当应用程序框架用于实现应用程序层时，它负责调用必要的API函数并实现所需的处理程序函数，从而允许设计人员专注于使用客户端API和框架回调的更高级别的应用程序处理。

  In the TMSP protocol, also available in SPI and UART variants, the host-side APIs are not dedicated functions made to be “similar” to the APIs used by SoC-based Thread applications. Instead, they are actually identical to the APIs and callbacks used on an SoC-based system with the abstraction to the host-side interfaces handled by the provided TMSP driver code. Additionally, TMSP drivers incorporate some functionality to manage the underlying IP layers on the NCP to improve coordination between upper layers of the stack shared across the NCP and its host.
  The main advantage to the NCP platform is its flexibility. The host processor can be as simple as an 8-bit microcontroller, or it can be something as sophisticated as a 64-bit computer with gigabytes of memory and a Windows or Linux operating system. This means that the NCP design is well-suited to scenarios where a device is being added on or retrofitted to an existing system, such that an OEM’s expertise and intellectual property on the software and hardware side can be leveraged to speed up the design cycle and expedite time to market. Another advantage to the NCP approach is that the host can provide significantly more resources (flash and RAM) and a different peripheral set for the application than the available SoC options. This allows for development of more complex applications with new features, and protects the application from exceeding the limitations of the SoC when significant new features are added to the application.
  Decoupling the stack processing from the application allows installing fixes and new features on the stack side with simple firmware updates to the NCP, without necessarily requiring any changes to the application firmware on the host. This decoupling also removes the CPU time constraints of sharing a processor with the stack. Because the NCP firmware manages the sleep state of the NCP to minimize its activity and its current consumption, only the host processor needs to be active when the application has tasks that don’t directly involve the stack. If the host processor’s active current consumption is lower than that of the SoC when the CPU is active without the radio, the total current consumed by the host and the NCP when running non-networking application tasks may actually be lower than the SoC in a comparable scenario.

• 在TMSP协议中，也提供SPI和UART变体，主机端API不是专用于与基于SoC的Thread应用程序使用的API“相似”的功能。相反，它们实际上与基于SoC的系统上使用的API和回调相同，其中抽象到由提供的TMSP驱动程序代码处理的主机端接口。此外，TMSP驱动程序包含一些功能来管理NCP上的底层IP层，以改善在NCP及其主机上共享的堆栈的上层之间的协调。
• NCP平台的主要优势在于其灵活性。主机处理器可以像8位微控制器一样简单，也可以像64位计算机那样复杂，具有千兆字节的内存和Windows或Linux操作系统。这意味着NCP设计非常适合在现有系统上添加或改装设备的场景，这样可以利用OEM在软件和硬件方面的专业知识和知识产权来加速设计周期和加快产品上市时间。 NCP方法的另一个优点是主机可以为应用程序提供比可用SoC选项更多的资源（闪存和RAM）和不同的外设集。这允许使用新功能开发更复杂的应用程序，并在应用程序中添加重要的新功能时保护应用程序不会超出SoC的限制。
• 将堆栈处理与应用程序分离后，可以在堆栈端安装修复程序和新功能，并对NCP进行简单的固件更新，而无需对主机上的应用程序固件进行任何更改。这种去耦还消除了与堆栈共享处理器的CPU时间限制。由于NCP固件管理NCP的睡眠状态以最小化其活动和当前消耗，因此当应用程序具有不直接涉及堆栈的任务时，仅需要主机处理器处于活动状态。如果在没有无线电的情况下CPU处于活动状态时主机处理器的有效电流消耗低于SoC的有效电流消耗，则在运行非网络应用任务时主机和NCP消耗的总电流实际上可能低于可比较的SoC场景。

  The primary disadvantage to the NCP approach is the addition of a second, host, processor, which adds extra cost and PCB real estate, and may impact the device’s overall power consumption. Another tradeoff is that decoupling stack and application processing means that certain time-sensitive interactions between the stack and the application can no longer occur in “real time” and must instead occur as notifications about decisions made by the stack after the fact. Thus, the host application has fewer opportunities to decide the outcome of certain decisions as they arise. Instead, “policies” are configured on the NCP to guide stack behavior in those situations. Also, because the NCP firmware is pre-built firmware supplied by Silicon Labs, the application designer does forfeit some amount of control over how the stack behaves and how its internal resources are allocated.
  Once you commit to using the NCP approach, you must then decide which host platform to use for the design. This platform may be different for the prototyping and final design stages, depending on the availability of materials and the flexibility required during the initial stages of debugging. When choosing a host platform, consider your existing expertise and available tools and resources on that platform, the cost and power consumption requirements of that platform, and the amount of memory available for application development, including any headroom needed for future enhancements. When developing a zigbee solution, you should also consider whether to use UART or SPI for EZSP communication. EZSP-UART requires a more complex driver, generally intended for use in a POSIX-compliant operating system, with more sophisticated logic and a larger memory footprint than the EZSP-SPI driver, and its supported maximum throughput is not as high. However, the EZSP-SPI implementation requires a few more interface pins than the EZSP-UART design. (A Portable Operating System Interface (POSIX)-compliant SPI driver for EZSP is also available but is often less portable across embedded Linux operating systems than the POSIX-compliant UART driver.) Because not all microcontrollers or operating systems support SPI, architectural constraints at the host may dictate this design choice. Thread’s TMSP has similar tradeoffs for SPI and UART. See AN912: SPI Host Interfacing Guide for Thread for more discussion about setting up a Thread host SPI driver.

• NCP方法的主要缺点是增加了第二个主机处理器，这增加了额外的成本和PCB空间，并可能影响设备的总体功耗。另一个权衡是解耦堆栈和应用程序处理意味着堆栈和应用程序之间的某些时间敏感的交互不再能够“实时”发生，而必须作为关于事后堆栈做出的决策的通知而发生。因此，主机应用程序在确定某些决策出现时的结果的机会较少。相反，在NCP上配置“策略”以指导这些情况下的堆栈行为。此外，由于NCP固件是Silicon Labs提供的预构建固件，因此应用程序设计人员会对堆栈的行为方式以及内部资源的分配方式进行一定程度的控制。
• 一旦您决定使用NCP方法，您必须决定使用哪个主机平台进行设计。该平台可能与原型设计和最终设计阶段不同，具体取决于材料的可用性和调试初始阶段所需的灵活性。在选择主机平台时，请考虑您在该平台上的现有专业知识和可用工具和资源，该平台的成本和功耗要求，以及可用于应用程序开发的内存量，包括未来增强所需的任何空间。在开发zigbee解决方案时，还应考虑是否使用UART或SPI进行EZSP通信。 EZSP-UART需要更复杂的驱动程序，通常用于符合POSIX标准的操作系统，具有比EZSP-SPI驱动程序更复杂的逻辑和更大的内存占用，并且其支持的最大吞吐量不是很高。但是，EZSP-SPI实现需要比EZSP-UART设计更多的接口引脚。 （适用于EZSP的便携式操作系统接口（POSIX）兼容SPI驱动程序也可用，但在嵌入式Linux操作系统中的可移植性通常低于符合POSIX标准的UART驱动程序。）因为并非所有微控制器或操作系统都支持SPI，所以架构限制在主持人可以决定这种设计选择。 Thread的TMSP对SPI和UART有类似的权衡。有关设置线程主机SPI驱动程序的更多讨论，请参见AN912：用于线程的SPI主机接口指南。

2.2.3不同的设计方法

• SoC与NCP相比,功能差异如下：

  Managing stack parameters, such as table sizes and allocation limits, and endpoint descriptor data, such as support clusters and profiles.

• SoC:Mainly set up through compile-time definitions built statically into the application binary.
• NCP:Managed by the NCP but configured by host at runtime after bootup of NCP and before engaging in any network activity; this interval is referred to as the “Configuration” phase and allows dynamic configuration of the NCP without rebuilding its firmware.

• 关于管理堆栈参数，例如表大小和分配限制，以及端点描述符数据，例如支持群集和配置文件。
  • SoC：主要通过编译时定义建立静态构建到应用程序二进制文件中。
  • NCP：由NCP管理，但在启动NCP之后和在参与任何网络活动之前由主机在运行时配置; 此间隔称为“配置”阶段，允许动态配置NCP上的参数而无需重建其固件。

  Application reaction to events’

• SoC The application can react to events, such as security authentication request, an incoming data poll from a child, or a remote binding modification, in the moment and can handle events on a case-bycase basis.
• NCP The host application configures policies ahead of time to pre-determine the outcome; notifications are after the fact.

• 应用对事件的反应
  • SoC：应用程序可以对事件做出反应，例如安全身份验证请求，来自子进程的传入数据轮询或远程绑定修改，并且可以逐个处理事件。
  • NCP：主机应用程序提前配置策略以预先确定结果;

  Polling (for sleepy end devices that need to poll the network periodically)
  The application framework takes care of the polling state machine, so the difference is negligible when it is used.

• SoC The application controls when each poll occurs and chooses how to react to the result of each poll.
• NCP The host application configures poll rate and failure tolerance. NCP handles polling with the configured rate, and only notifies the host when the failure rate surpasses the configured threshold. This can make the application state machine design easier on host platforms if not using an application framework.

  Managing message buffers
  The application framework handles SoC buffer management, so the difference is negligible when it is used.

• SoC The application shares memory for packet data with the stack. Shared message buffers must be allocated by the application for outgoing message data, and by the stack for incoming or relayed
  message data. Buffer management process, including buffer allocation/deallocation and construction, can be tricky and is often the source of errors in SoC application design.
• NCP NCP handles the buffer management itself and accepts / delivers message payload data as a simple array and a length argument. This makes messaging interface simpler and less error-prone if not using an application framework.

• 轮询（适用于需要定期轮询网络的睡眠终端设备）
• 应用程序框架负责轮询状态机，因此在使用时差异可以忽略不计。
  • SoC：应用程序控制每次轮询发生的时间，并选择如何对每个轮询的结果做出反应。
  • NCP：主机应用程序配置轮询速率和容错。 NCP使用配置的速率处理轮询，仅在故障率超过配置的阈值时通知主机。 如果不使用应用程序框架，这可以使主机平台上的应用程序状态机设计更容易。

  Handling zigbee source routing, where the application is expected to handle incoming Route Record notifications and preserve this data in a “source route table”

• SoC Source route table resides on SoC; its size is constrained by the SoC’s limited RAM resources.
• NCP NCP can collect the last N source routes in its own internal source route table, where N is sized by the host application during configuration. However, the host receives route record data in callbacks from the NCP and can generally buffer much more route data than the NCP, depending on the host’s RAM constraints. This makes the High RAM Concentrator operation (often used for gateways, commissioning/configuration tools, and other major aggregation points) more feasible on an NCP platform than on an SoC platform, especially those SoC platforms where RAM availability is limited.

• 处理zigbee源路由，期望应用程序处理传入的路由记录通知并将此数据保存在“源路由表”中
  • SoC：源路由表驻留在SoC上; 它的大小受到SoC有限的RAM资源的限制。
  • NCP ：NCP可以在其自己的内部源路由表中收集最后N个源路由，其中N在配置期间由主机应用程序调整大小。 但是，主机从NCP接收回调中的路由记录数据，并且通常可以缓冲比NCP多得多的路由数据，具体取决于主机的RAM约束。 这使得高RAM集中器操作（通常用于网关，调试/配置工具和其他主要聚合点）在NCP平台上比在SoC平台上更可行，尤其是那些RAM可用性有限的SoC平台。

  Adding and Removing Core Networking and Radio Functionality

• SoC When changing the core (stack) functionality in an SoC application, you need only add or remove libraries or source code from a single application. This is easily done using the application framework by changing the plugins to be included.
• NCP If you want to change the core (stack) functionality in your host plus NCP application, you must make changes to both the host processor application and the NCP firmware. This can be slight hindrance to the application development process, but the Network Coprocessor Application Framework can help with this. This application framework provides an interface to build NCP applications that include only selected pieces of core networking and radio functionality.

• 添加和删除核心网络和无线电功能
  • SoC：在更改SoC应用程序中的核心（堆栈）功能时，只需在单个应用程序中添加或删除库或源代码。 通过更改要包含的插件，可以使用应用程序框架轻松完成此操作。
  • NCP：如果要更改主机和NCP应用程序中的核心（堆栈）功能，则必须更改主机处理器应用程序和NCP固件。 这可能会对应用程序开发过程造成轻微阻碍，但网络协处理器应用程序框架可以为此提供帮助。 该应用程序框架提供了构建NCP应用程序的接口，该应用程序仅包括选定的核心网络和无线电功能。