作者主页(文火冰糖的硅基工坊)：文火冰糖（王文兵）的博客_文火冰糖的硅基工坊_CSDN博客
本文网址：https://mp.csdn.net/mp_blog/creation/editor/117590399
目录
3.2.9 nFAPI Configuration TLVs
4.2.1 Handling of Pointer Option in FAPI Messages
4.2.2 Extraction of FAPI Messages From an nFAPI Message
第1章 简介
2.1 nFAPI接口的主要消息流程
2.2 5G nFAPI接口与4G FAPI的共存
相对于FAPI接口nFAPI接口无非就是增加了三类消息：
（1）在P5接口上：用于VNF对PNF进行管理、配置的消息。
（2）在P7接口上：用于VNF与PHY之间进行UL/DL上下行时隙同步的消息。
（3）在P5和P7接口，用于透传FAPI接口的P5和P7消息的消息。
采用SCTP协议作为传输层的好处是，SCTP是可靠的传输层，应用层不需要对传输进行定时、合法性检查、包的丢失检查等。
对于5G nFAPI payload标识PPI=TBA.
SCTP连接由PNF发起，根据OAM配置的VFN的IP地址和端口号，与VFN建立的SCTP流，每个PNF PHY与VFN都有一个独立的SCTP流，用于在PHY与VNF之间传送配置、命令消息。
SCTP协议支持在两个端点之间建立冗余的连接。
nFAPI P7对传输延迟和传输抖动有严格的要求，则就限制了为了提高传输可靠性的支持传送的传输层协议的使用，如TCP。nFAPI P7业务数据面采用UDP作为传输层协议，这就需要应用层通过序列号确保数据包传输的完整性，确保传输过程中没有数据包的丢失。
在VNF和PNF上使用的IP地址和端口，是通过P5接口交换PHY配置获取的。
而P7消息头中的PHY ID，用于指向哪个PHY实例/VNF接口。
这些配置选项允许具有多个PHY实例的PNF使用单个UDP流，或者每个PHY实例使用一个UDP流。
nFAPI接口允许在VNF与PNF之间建立IPSec隧道，P5和P7接口协议在IPSec隧道中传输。
nFAPI PDU组成：nFAPI PDU header + n个消息组成；
而每个消息又由消息头Hdr + 消息体body组成。
如下图所示：
上图中：
如果传输机制需要，nFAPI头允许对消息进行分段。
nFAPI定义了三种大类型的消息
为了避免冲突，所有消息ID必须规划。
2.3.2.3.1 Dedicated nFAPI messages：nFAPI专有的消息
nFAPI新增加了VNF和PNF设备，上述消息是VNF与PNF设备之间的交互消息。一个PNF可以创建多个物理层PHY的实体。
2.3.2.3.2 Combined messages: 组合/混合消息
2.3.2.3.3 Transparent messages:透传消息
相对于nFAPI，FAPI是嵌入式的，因此没有定义VNF和PNF, 只定义L2和L1的接口操作。因此上述消息MAC与物理层之间交互的消息。
2.3.2.3.3 厂家可扩展的消息
nFAPI消息体由零个或多个TLV结构组成，TLV参数定义为在后续部分中描述。
nFAPI消息包装器中嵌入的nFAPI消息（报头和TLV）以及FAPI消息（报头和TLV）中的字段将以大端顺序（网络字节和位顺序）格式排列。
2.3.4.1 P5信令消息
PNF根据OAM接口对SCTP End point的配置，发起与VNF的SCTP连接，这个连接是双向的数据流通信，一旦SCTP连接建立成功，VNF与PNF PHY之间就可以进行双向通信。
关于SCTP消息的通信，请参考SCTP协议。
2.3.4.2 P7信令消息
P7用户面接口采用UDP通信。UDP是一种无连接协议，它依赖于应用层来处理丢失和无序的消息。为此，P7协议头定义了每个PHY实例上的段号和序列号，以允许nFAPI P7应用程序根据此信息处理丢包和失序问题。当P7接口上的接收端识别到丢失或无序的消息时，接收实体负责处理此类情况。这意味着对于基于slot调度中的PNF，PNF需要缓冲和重排接收到的消息，处理任何的无序或分段的消息，这些消息需要一些额外的时间来处理。有关这些情况的处理，请参阅第2.1.3.4节和第2.1.3.5节。
该消息是由VNF发起，通过该消息，VNF获取PNF的能力参数。该消息没有消息体。
该消息是VNF对PNF_PARAM.request的应答消息，消息格式如下
消息的内容是通过TLV格式进行反馈的，TLV的好处是消息体的结构可以非常灵活和可伸缩性强。
3.1.2.1 TLV的内容
（1）nFAPI Sync Mode：该参数指明了PHY实例的同步方式
（2）Location Mode：该参数指明了同步源
3.1.2.2 PNF PARAM.response Errors
当VNF处于IDLE状态时，该消息用于VNF对PNF进行配置管理。
当VNF处于CONFIGURED状态时，该消息用于VNF对PNF进行重新配置。
消息体的内容是TLV格式，但本标准并没有定义具体的TLV。各个厂家可以采用vendor自定义的TLV对PHY进行配置。
该消息用于VNF启动PNF, 该消息没有消息体。
该消息用于VNF停止PNF的运行，使得PNF从RUNNING状态切换到CONFIGED状态。
PNF在收到该消息后，需要reset所有的PHY实体。
该消息没有消息体。
当PNF处于RUNNING状态，PHY处于IDLE状态时，该消息用于VNF获取PHY的能力和配置。消息体的格式由FAPI规范定义。
该消息用于PHY向VNF反馈自身的整体的能力和选项。
消息体的格式如下：
PHY与VFN之间的同步参数，这些参数非常重要
该消息用于VFN对PHY进行配置，消息格式如下:
可配置的参数如下所示：
OAM配置的VNF IP地址和端口号，用于PHY与VNF建立连接。
PHY对VNF的CONFIG.request的响应。
该消息用于VNF启动PHY, TLV消息体与FAPI一致，nFAPI没有新定义新的TLV.
该消息用于PHY向VNF指示内部错误信息, TLV消息体与FAPI一致，nFAPI没有新定义新的TLV.
该消息用于VNF停止PHY, TLV消息体与FAPI一致，nFAPI没有新定义新的TLV。
有PHY主动向VNF上报STOP实践，TLV消息体与FAPI一致，nFAPI没有新定义新的TLV。
这些TLV参数，可以用于PARAM.xxx and CONFIG.xxx消息交互。
一个DL Node Sync和UL Node Sync消息交互完成后，VNF获取了t1, t2, t3, t4这4个时间戳。通过这个时间戳，可以计算出如下的信息：
演算过程如下：
（1）前提：
（2）计算过程：
t2 + offset = t1 + delay =>delay – offset = t2 – t1
t4 = t3 _+ offset + delay => delay + offset = t4 – t3
delay = [ (t4-t3) + (t2-t1)]/2
offset = [ (t4-t3) - (t2-t1)]/2
通过公式，VNF很容易计算出VNF与PNF之间的传输延时delay以及PNF的10ms帧的起始TTI相对于VNF的10ms帧的起始TTI时间的偏移offset。
然后通过就可以通过CONFIG.request对VNF的TTI进行修正。或者VNF修正自己的TTI, 确保VNF和PNF之间的TTI是对齐的（包含网络传输延时）。
该信息是由PNF向VNF提供TLV信息。
这些信息是PNF自身统计的各种数据的延时抖动。
在PNF PHY与VNF的10m帧的起始TTI对齐后，由于网络传输延时的变化，导致
PNF PHY收到的上下行调度消息、UL_DCI指示、VNF下行发送数据消息的时间，并不是稳定不变的，存在一个延时抖动，PNF PHY参照自己当前的10m帧的起始TTI, 对收到这些消息的时间的抖动性进行统计。
影响PNF PHY接收到数据的时间的抖动性的因素有：
nFAPI并没有定义新的透传 P7 TLV.
FAPI接口是基于板内通信的系统，因此PHY和MAC层可以共享内存访问相同的内存空间，nFAPI针对的是跨网元的板间通信系统，因此通过FAPI 消息偿传递数据时，这两种接口是有差别的。如果透明FAPI消息包含用于指定消息的有效负载部分的指针选项，则通过nFAPI携带的FAPI消息不应使用指针选项。
在nFAPI协议中，需要对透明FAPI消息进行格式化，以便只需复制消息位即可从nFAPI消息中提取FAPI消息，如下图展示了一个nFAPI PDU中承载2个FAPI消息的情形。
作者主页(文火冰糖的硅基工坊)：文火冰糖（王文兵）的博客_文火冰糖的硅基工坊_CSDN博客
本文网址：https://mp.csdn.net/mp_blog/creation/editor/117590399
