目前, 主流的手部姿态估计的技术方案是使用马普所于2017年提出的MANO参数化模型, 在此基础上回归3D坐标, 这是因为MANO有很合理的结构以及定义好的前向动力学树。本文的目的在于为大家介绍，基于MANO的手部姿态估计的流程：包括并不限于: 数据处理，MANO的推理流程(与论文对齐)，手的解剖学和生物学特点。

1. 什么是手部姿态估计？

我理解的 手部姿态估计(hand pose estimation) 是:
同人体姿态估计一样, 是给定一张手部特写图片，估计其姿态(2D/3D keypoint)的位置(通常是21个).

下图是一个最经典的实现(无参数化模型):

将一个手部特写图片(hand image)输入Encoder-Decoder结构中，从Decoder输出的特征图中，选取响应最大的位置，与ground truth生成2D landmark的热力图计算loss，目的是让Decoder生成的特征图在手部的不同位置有对应的响应，即从point of interest (PoI)变为构造一种regional of interest (RoI)的表示, 即让网络从关注某个确定的点，到关注一个范围, 以此扩大模型的泛化能力以及对复杂情况下的估计鲁棒性.

这种方法在参数化模型MANO/SMPL出现之前，是姿态估计领域的主流叙事.

此图来自2018年，Olha CHERNYTSKA(毕业于乌克兰天主教大学)的硕士毕业论文[3].

其中3D keypoint的坐标一般用相对坐标系表示, 对手部来说，一般会选择手腕(下图的0)/食指和手掌连接关节(下图5)作为局部坐标系的原点(0, 0, 0). 这种做法也叫做root-relative.

下图是以上图的节点5为原点的相对3D坐标表示，以下图为例, 我们想让节点5的坐标为(0, 0, 0)，在实践中，大家的做法一般很简单(伪代码):

img = cv2.imread("xxx.jpg")  # 1) 读取手部特写图片
img = normalize(img)         # 2) 对图片进行处理(规则化等)
pred_3d = Net(img)           # 3) 送入网络进行预测
pred_3d -= pred_3d[5]        # 4) 将预测结果变为root-relative的方式.

红框就是节点5，可见其坐标为(0, 0, 0).

2. MANO是什么？

近年来, CVPR, ECCV, ICCV的手部姿态估计论文，基本或多或少的都是model-based, 即基于参数化模型的方案。而其中，最主流的参数化模型就是Javier Romero, Dimitrios Tzionas, Michael J. Black于2017年发表于Siggraph Asia的《Embodied Hands: Modeling and Capturing Hands and Bodies Together》[1].

这篇文章也是在马普所和工业光魔联合提出的《SMPL: A Skinned Multi-Person Linear Model(2015)》[2]的基础上，提出了针对手部的参数化模型，其主要目的是:

To cope with low-resolution, occlusion, and noise, we develop a
new model called MANO (hand Model with Articulated and Non-rigid defOrmations).
图来自[1].

我的个人感受是，由于手势姿态估计的问题是:

• 自遮挡: 以下图为例，中指到小指都被手背挡住了.
  

• 手抓握物体导致的遮挡:
  

• 分辨率低: 手部在整个构图中的所占像素比例非常小，对正确估计其手势增加了难度.

确实，在全身/半身的时候， 手势相比整体来说所占的像素非常小 ，所以 难
以分辨其动作 MANO这个模型，相当于在图片 ->3D pose中间加了一个过渡表示(或者说加上了强经验prior，从而能够预测遮挡和低分辨率的图像）.

图来自Frankmocap仓库[4]

用不带先验信息的方法，即model-free的方法，对于这些情况的姿态估计效果通常就会失败。而自从有了参数化模型MANO，由于MANO是由 “1000 high-resolution 3D scans of hands of 31 subjects in a wide variety of hand poses.” 得到，其中包括抓握，不良光照等场景。

所以，根据18年以来的众多手部姿态分析工作表明：使用MANO参数化模型，对于估计出一个合理且准确的手部姿态，有至关重要的作用。

需要注意的是，由于手部是分段刚性的(articulated objects), 因此手部的建模还是有一定难度的，马普所用了来自美国亚特兰大的3dMD公司的扫描设备，估计花费不菲…, 至于MANO是怎么制作的，这里我不详细展开，有兴趣的朋友可以直接在文章下面问。

图来自中科大刘利刚老师的games102课程[5].

那么，MANO作为一个 3D参数化模型，其参数都有哪些呢？

• 778个vertices 1538个faces，并根据 16个 关键点 +从顶点中获取 5个
  手指指尖的点， 构成完整的手部链条，或者叫做前向动力学树 (forward kinematic tree).
  下图来自牛津大学的CVPR2019论文[7]《3D Hand Shape and Pose from Images in the Wild》.
  

(即图中的 ,16,17,18,19,20都是由变形后的 vertex中按照规定规则取到的 , 代码. 以节点9为例，其3D坐标可以在变形后的Mesh上，根据其所在顶点(vertex)去提取。

3. 手势3D pose estimation的MANO部分处理逻辑分析重点

如下图所示， 手部的crop图片送入神经网络，预测得到 MANO所需的61个参数的值，其中包含 MANO所需的相机参数 (前 3个 ), θ(3-51), β(51:61)，其中θ是MANO中用于控制pose的参数，β则是 MANO中用于控制shape的参数。

其中，神经网络的设计就比较简单，只要按照输入和输出的结构设计就行， 最经典的实现方案是UCB和马普所合作的CVPR2018论文: HMR[6], 其使用了auto-regressive的方式去优化预测的MANO所需的61个系数.

• 输入(bs,3,224,224)
  为图像处理后得到的Tensor(NCHW，图像的分辨率可以按照自己的需求调整), bs是batch size.

• 输出为(bs, 61)
  得到MANO所需的参数, 这些参数输入MANO, 我们就可以得到3D的pose estimation结果(相对坐标系下的21个关键点的xyz位置).

3.1 MANO的计算逻辑

下图来自CVPR2020的《Minimal-Hand》[8], 其把MANO的流程简单用两个公式概况了:

• ① $T(\beta ,\theta )=\overline{T}+B_s(\beta )+B_p(\theta )$
  此公式是将shape的参数$\beta \in R^{10}$ 和pose的参数$\theta \in R^{48}$进行变形，变形的实现通过$B_{s/p}$实现。$\overline{T}$表示一个标准的3D 手部mesh, 下图就是MANO的hand_mean $\overline{T}$:

可以看到, MANO的$\overline{T}$是一个手掌摊平的姿势, 在动画领域，一般称为T型姿势（T-pose）.

变形示意图:

• ② $M(\beta ,\theta )=\mathbf{W}(T(\theta ,\beta ),\theta ,\beta ,W,J(\theta ))$
  通过第①步，我们得到变形后的mesh: $T(\theta ,\beta )$, 第②步的目的就是进行蒙皮操作(linear blend skinning), $W$是蒙皮权重，$J(\theta )$是节点的位置.
  

3.2 MANO的实际计算流程

好了，在了解了MANO的基本流程后，让我们回归正题，本篇文章的目的 是分析 MANO究竟是如何处理cam, shape, pose的参数，来得到 (21, 3)的 joint rotation(axis-angle表示)的？

这里以下面的的rot_pose_beta_to_mesh函数为核心进行分析, 其中, rot_pose_beta_to_mesh接收3个入参, 拼起来正好是网络预测出来的61个参数:

• rots $\in R^3$
  root节点(手腕CMC)的旋转axis-angle.
• poses $\in R^{45}$
  除每个手指指尖外(除TIP这一排)和手腕外，所有的关键点的axis-angle (15*3=45), 下图来自ECCV2020 BMC[9]
  

手部的骨骼分为灰色的手腕(CMC), 黄色的MCP(手掌和各个手指的交界处), 绿色的PIP, 蓝色的DIP以及表示指尖位置的骨骼TIP。 可见，骨骼是“横着”来命名的…

• betas $\in R^{10}$
  mano所需要的shape参数

3.2.1 MANO的一些参与计算的重要参数

• kintree_table, parent 等动力学与继承关系参数
  如下图所示，parent和 kintree_table组建了手势的链条
  
  注意，kintree_table是 不包含指尖 的 ！！(只有 16个 joints 15个手指的 joints+1个 wrist joint)，也符合 MANO定义的结构形式，即没有上图的(4,8,12,16,20)这5个点.

• hands_mean: 和 mesh_mu类似，这里的 hands_mean应该
  是rest的手的axis-angle， 其用法是用来加上网络预测的 pose (axis-angle)，再对其进行处理。
  需要注意的是，这里的pose除了不包含TIP骨骼外，还不包括手腕.
  

• mesh_mu: 下图 (MANO2017[1])的公式 2的 $\overline{T}$. 即平均 shape。
  
  公式2的计算得到的$T_p$对应代码中的$v_{posed}$:
  

• mesh_pca: 对应最大的 shape特征值的特征向量 , 因为 shape是根据pca取最大的 10维参数作为 shape的，这里的 mesh_pca根据其用法，是公式 4(MANO2017)里面的Sn。
  
  对应代码:
  

• J_regressor: 对应 (SMPL2015)的公式10, 其目的是: 将mesh上的顶点 (vertices)变为节点 (joints).
  

• root_rot: 根节点, 是指手腕的那个点 即下图的 0点 ，我理解这里应该是用这种方式来计算相对的距离。
  

• posedirs: 根据之前的分析， posedirs就是MANO(2017)中公式3中的Pn, 表示pose的blend shape参数.
  

• weights: weights就是3.1中公式2$$M(\beta ,\theta )=\mathbf{W}(T(\theta ,\beta ),\theta ,\beta ,W,J(\theta ))$$的$W$.

3.2.2 旋转矩阵计算(Rodrigues)

这里主要分析的是rodrigues函数，此函数的目的是把轴向角(axis-angle)变为旋转矩阵(rotation matrix)[10].

下面代码里的n等于下图(SMPL2015)的unit norm axis of rotation $\overline{w}$, R

R = I3 + torch.sin(theta).view(-1, 1, 1) * Sn \
    + (1. - torch.cos(theta).view(-1, 1, 1)) * torch.matmul(Sn, Sn)

等于SMPL2015的公式 (1), S(n_)函数对应的就是上面的Skew(V).

def rodrigues(r):
    theta = torch.sqrt(torch.sum(torch.pow(r, 2), 1))

    def S(n_):
        ns = torch.split(n_, 1, 1)
        Sn_ = torch.cat([torch.zeros_like(ns[0]), -ns[2], ns[1], ns[2], torch.zeros_like(ns[0]), -ns[0], -ns[1], ns[0],
                         torch.zeros_like(ns[0])], 1)
        Sn_ = Sn_.view(-1, 3, 3)
        return Sn_

    n = r / (theta.view(-1, 1))
    Sn = S(n)

    # R = torch.eye(3).unsqueeze(0) + torch.sin(theta).view(-1, 1, 1)*Sn\
    #        +(1.-torch.cos(theta).view(-1, 1, 1)) * torch.matmul(Sn,Sn)

    I3 = Variable(torch.eye(3).unsqueeze(0).cuda())
	
	# R等于 公式 (1)---SMPL
    R = I3 + torch.sin(theta).view(-1, 1, 1) * Sn \
        + (1. - torch.cos(theta).view(-1, 1, 1)) * torch.matmul(Sn, Sn)

    Sr = S(r)
    theta2 = theta ** 2
    R2 = I3 + (1. - theta2.view(-1, 1, 1) / 6.) * Sr \
         + (.5 - theta2.view(-1, 1, 1) / 24.) * torch.matmul(Sr, Sr)

    idx = np.argwhere((theta < 1e-30).data.cpu().numpy())

    if (idx.size):
        R[idx, :, :] = R2[idx, :, :]

    return R, Sn

3.2.3 get_poseweights (poses, bszie)

此函数用于计算 pose_weights属性， 其 shape为 [bs, 135], 而 $135=45\ast 3$.

其分为 2步：

• ① 先将 poses([bs, 16, 3])送 入3.2.2所介绍的rodrigues函数中, 按照SMPL2015的说法， 其目的是将每个joint的 axis-angle转为rotation matrix.
  pose_matrix为 [15xbs, 3, 3]
  

• ② pose_matrix 减去单位矩阵, 理解为 (MANO2017)公式 3的 $R_n(\theta )-R_n({\theta }^{\ast })$:
  

def get_poseweights(poses, bsize):
    # pose: batch x 24 x 3
    pose_matrix, _ = rodrigues(poses[:, 1:, :].contiguous().view(-1, 3))
    # pose_matrix, _ = rodrigues(poses.view(-1,3))
    pose_matrix = pose_matrix - Variable(torch.from_numpy(
        np.repeat(np.expand_dims(np.eye(3, dtype=np.float32), 0), bsize * (keypoints_num - 1), axis=0)).cuda())
    pose_matrix = pose_matrix.view(bsize, -1)
    return pose_matrix

3.3 rot_pose_beta_to_mesh梳理

① 第一步 是 计算 poses和 v_shaped.

⚫ poses: poses是网络预测的axis angle + hand_mean (rest pose), 再加上 root_rot(wrist的位置， 代码里面写为 (0,0,0), 是相对位置, 构造root-relative的结果). [bs, 16, 3]

⚫ v_shaped: 对应 SMPL2015的公式10里面的$\overline{T}$+ Bs部分. [bs, 778, 3]

对应代码:

② 第 2步 是 计算 pose_weights, v_posed和 J_posed.

⚫ pose_weights 是 通过

pose_weights = get_poseweights(poses, batch_size)

计算得到的。具体分析看 3.2.3的get_poseweights函数的介绍.

⚫ v_posed 是 <3D Hand Shape and Pose from Images in the wild, CVPR2019>的公式 2的 $T(\beta ,\theta )$, 也是 MANO2017的公式 2:

⚫ J_posed 是 SMPL2015的 公式 10 其 作用 是 将 vertices变为 joints。([bs, 16, 3])

③ 第3步是 计算 results_global, 和 T, v.

⚫ 从J_posed (bs, 16, 3)变为J_posed_split(16, bs, 3). 即这里的处理逻辑是按手指的节点去处理, 而非batch-wise维度的。

⚫ 同理， 有从poses得到的poses_split, 再由poses_split得到angle_matrix.

⚫ results_global是根据 kinematic tree来计算的. 每个当前节点的joint location是根据其父节点以及当前节点的旋转矩阵进行矩阵相乘得到的.

results_global也是16个手指节点的 3D xyz. [(bs ,4, 4), (bs, 4, 4), … , (bs ,4, 4)].

注意， 父节点只是当前节点的上面一个节点， 而非根节点哦~。之前有图解释过这个问题.

⚫ T是根据前面的results和weights相乘得到的，这里的 weights是蒙皮blend weights $W$.

⚫ V是 经过蒙皮处理后的最终变形节点, Jtr是最终的手部节点 3D位置的集合， 需要注意的是，**指尖(TIP骨骼)**的5个joint的位置是根据 V得到 的.
而且，
V和 Jtr是要再旋转 (根据root节点的旋转角)一下输出的才是最终正确结果.

④ 最后一步，要从标准的MANO模型里，取TIP骨骼的joint的位置，
这个取法需要手动的去MANO模型里看顶点，以大拇指为例，这里取得是745号顶点：

然后，就把顶点v和节点Jtr都根据root节点(手腕)的旋转矩阵进行旋转。

最后的最后，为了得到局部坐标系的3D坐标(root-relative)，我们进行的处理是以节点5为(0, 0, 0)，所以，把V和 Jtr都要减去5号节点的位置。

4. 总结

根据上面的分析，我们最终得到了每个手部图像对应的21个关键点的3Dxyz（root-relative）和扭转后的所有778个顶点(MANO的手部模型有778个顶点)。

有任何问题欢迎提问，交流~

参考文献

[1] MANO2017
[2] SMPL2015
[3] OlgaChernytska/3D-Hand-Pose-Estimation
[4] Frankmocap Facebook
[5] 《几何建模与处理基础》Geometry Modeling and Processing (GMP)
[6] HMR CVPR2018
[8] Minimal Hand CVPR2020
[9] hand-biomechanical-constraints (ECCV2020)
[10] 旋转矩阵（Rotation matrix）：旋转轴与旋转角 ( axis and angle )

普及原因：

MANO有很合理的结构以及定义好的前向动力学树

描述：

MANO（具有关节和非刚性变形的手模型）的新模型

手部姿态估计：

姿态(2D/3D keypoint)的位置(通常是21个).

最经典的实现：

2018年，Olha CHERNYTSKA(毕业于乌克兰天主教大学)的硕士毕业论文

3D keypoint的坐标及实现伪代码

 

针对手部的参数化模型，主要目的

1、应对低分辨率：手部在整个构图中的所占像素比例非常小，对正确估计其手势增加了难度.在全身/半身的时候， 手势相比整体来说所占的像素非常小 ，所以难以分辨其动作 MANO模型相当于在图片 ->3D pose中间加了一个过渡表示(或者说加上了强经验prior，从而能够预测遮挡和低分辨率的图像

2、遮挡：主要是自遮挡和手握物体导致的遮挡

3、噪声

MANO作为一个 3D参数化模型，其参数都有哪些呢？

778个vertices 1538个faces，并根据 16个 关键点 +从顶点中获取 5个手指指尖的点， 构成完整的手部链条，或者叫做前向动力学树 (forward kinematic tree).

手势3D pose estimation的MANO部分处理逻辑分析重点

其中，神经网络的设计就比较简单，只要按照输入和输出的结构设计就行，

最经典的实现方案是UCB和马普所合作的CVPR2018论文: HMR[6], 其使用了auto-regressive的方式去优化预测的MANO所需的61个系数.

输入(bs,3,224,224)为图像处理后得到的Tensor(NCHW，图像的分辨率可以按照自己的需求调整), bs是batch size.输出为(bs, 61)得到MANO所需的参数,

这些参数输入MANO, 我们就可以得到3D的pose estimation结果(相对坐标系下的21个关键点的xyz位置).

3.1 MANO的计算逻辑

CVPR2020的《Minimal-Hand》[8], 其把MANO的流程简单用两个公式概况了:1、变形mesh  2、蒙皮

3.2 MANO的实际计算流程

目的 :分析 MANO如何处理cam, shape, pose的参数，得到 (21, 3)的 joint rotation(axis-angle表示)

以rot_pose_beta_to_mesh函数为核心进行分析, 其中, rot_pose_beta_to_mesh接收3个入参, 拼起来正好是网络预测出来的61个参数:

手部的骨骼分为灰色的手腕(CMC), 黄色的MCP(手掌和各个手指的交界处), 绿色的PIP, 蓝色的DIP以及表示指尖位置的骨骼TIP。 骨骼是“横着”命名的…

3.2.1 MANO的一些参与计算的重要参数

kintree_table, parent 等动力学与继承关系参数：如下图所示，parent和 kintree_table组建了手势的链条

kintree_table不包含指尖 的 ！(只有 16个 joints 15个手指的 joints+1个 wrist joint)，也符合 MANO定义的结构形式

hands_mean: 和 mesh_mu类似，这里的 hands_mean应该是rest的手的axis-angle， 其用法是用来加上网络预测的 pose (axis-angle)，再对其进行处理。
需要注意的是，这里的pose除了不包含TIP骨骼外，还不包括手腕.

mesh_pca: 对应最大的 shape特征值的特征向量 , 因为 shape是根据pca取最大的 10维参数作为 shape的，这里的 mesh_pca根据其用法，是公式 4(MANO2017)里面的Sn。

J_regressor: 对应 (SMPL2015)的公式10, 其目的是: 将mesh上的顶点 (vertices)变为节点 (joints).

root_rot: 根节点, 是指手腕的那个点 即下图的 0点 ，这里应该是用这种方式来计算相对的距离。

posedirs: 根据之前的分析， posedirs就是MANO(2017)中公式3中的Pn, 表示pose的blend shape参数.

weights: weights就是3.1中公式2的W

3.2.2 旋转矩阵计算(Rodrigues)

主要分析的是rodrigues函数，此函数的目的是把轴向角(axis-angle)变为旋转矩阵(rotation matrix)

3.2.3 get_poseweights (poses, bszie)

此函数用于计算 pose_weights属性， 其 shape为 [bs, 135], 而 135 = 45 ∗ 3
其分为 2步：

def get_poseweights(poses, bsize):
    # pose: batch x 24 x 3
    pose_matrix, _ = rodrigues(poses[:, 1:, :].contiguous().view(-1, 3))
    # pose_matrix, _ = rodrigues(poses.view(-1,3))
    pose_matrix = pose_matrix - Variable(torch.from_numpy(
        np.repeat(np.expand_dims(np.eye(3, dtype=np.float32), 0), bsize * (keypoints_num - 1), axis=0)).cuda())
    pose_matrix = pose_matrix.view(bsize, -1)
    return pose_matrix

3.3 rot_pose_beta_to_mesh梳理

① 第一步 是 计算 poses和 v_shaped.

⚫ poses: poses是网络预测的axis angle + hand_mean (rest pose), 再加上 root_rot(wrist的位置， 代码里面写为 (0,0,0), 是相对位置, 构造root-relative的结果). [bs, 16, 3]

⚫ v_shaped: 对应 SMPL2015的公式10里面的

对应代码：

② 第 2步 是 计算 pose_weights, v_posed和 J_posed.

⚫ pose_weights 是 通过

pose_weights = get_poseweights(poses, batch_size)

计算得到的。具体分析看 3.2.3的get_poseweights函数的介绍.

⚫ v_posed 是 <3D Hand Shape and Pose from Images in the wild, CVPR2019>的公式 2的 T ( β , θ ) T(β, θ)T(β,θ), 也是 MANO2017的公式 2:

⚫ J_posed 是 SMPL2015的 公式 10 其 作用 是 将 vertices变为 joints。([bs, 16, 3])

③ 第3步是 计算 results_global, 和 T, v.

⚫ 从J_posed (bs, 16, 3)变为J_posed_split(16, bs, 3). 即这里的处理逻辑是按手指的节点去处理, 而非batch-wise维度的。

⚫ 同理， 有从poses得到的poses_split, 再由poses_split得到angle_matrix.

⚫ results_global是根据 kinematic tree来计算的. 每个当前节点的joint location是根据其父节点以及当前节点的旋转矩阵进行矩阵相乘得到的.

results_global也是16个手指节点的 3D xyz. [(bs ,4, 4), (bs, 4, 4), … , (bs ,4, 4)].

注意， 父节点只是当前节点的上面一个节点， 而非根节点

⚫ T是根据前面的results和weights相乘得到的，这里的 weights是蒙皮blend weights W 

⚫ V是 经过蒙皮处理后的最终变形节点, Jtr是最终的手部节点 3D位置的集合， 需要注意的是，**指尖(TIP骨骼)**的5个joint的位置是根据 V得到 的.
而且，V和 Jtr是要再旋转 (根据root节点的旋转角)一下输出的才是最终正确结果.

④ 最后一步，要从标准的MANO模型里，取TIP骨骼的joint的位置，
这个取法需要手动的去MANO模型里看顶点，以大拇指为例，这里取得是745号顶点：

然后，就把顶点v和节点Jtr都根据root节点(手腕)的旋转矩阵进行旋转。

最后的最后，为了得到局部坐标系的3D坐标(root-relative)，我们进行的处理是以节点5为(0, 0, 0)，所以，把V和 Jtr都要减去5号节点的位置。

4. 总结

根据上面的分析，我们最终得到了每个手部图像对应的21个关键点的3Dxyz（root-relative）和扭转后的所有778个顶点(MANO的手部模型有778个顶点)。

 

 

 

仓参考博客：https://blog.csdn.net/g11d111/article/details/115539407?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522162064936616780261988804%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=162064936616780261988804&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_v2~rank_v29-4-115539407.first_rank_v2_pc_rank_v29&utm_term=mano.tonskeleton

 

 

 

 

 

网络功能虚拟化（NFV）提供了一种设计、部署和管理网络服务的全新方式，NFV将网络功能如网络地址转换（NAT）、防火墙、入侵检测、域名服务和缓存等功能从专有硬件中分离出来，并通过软件加以实现。NFV能够整合和交付完全虚拟化基础设施所需的网络组建，包括虚拟服务器、存储等。

NFV具备以下优势：

• 降低CAPEX：减少企业对专有硬件的需求，并且提供了按需付费的模式
• 降低OPEX：简化网络服务的推出和管理
• 加快服务投入市场的时间：减少部署新服务的时间，能够有效应对不断变化的业务需求，抓住市场机遇提高投资回报率。
• 提供无与伦比的敏捷性和灵活性：能够根据需求扩大或降低服务，能够在商用标准服务器上以软件实现业务创新。

什么是MANO？

由于NFV需要大量的虚拟化资源，因此需要高度的软件管理，业界称之为编排。业务流程编排、连接、监控和管理NFV服务平台所需的资源，业务流程可能需要对很多网络和软件元素进行编排包括库存系统、计费系统、配置工具和OSS等。

NFV MANO（网络功能虚拟化管理和编排）是用于管理和协调虚拟化网络功能（VNF）和其他软件组件的架构框架。欧洲电信标准协会（ETSI）行业规范组（ISG NFV）定义了MANO架构，以便在与专用物理设备分离并移动到虚拟机（VM）时促进服务的部署和连接。

（ETSI发布的MANO架构图）

MANO能做什么？

NFV MANO有三个主要功能块：NFV编排器，VNF管理器和虚拟基础设施管理器（VIM）。总而言之，这些模块在整个网络需要时负责部署、连接功能和服务。

• NFV编排器由两层构成：服务编排和资源编排，可以控制新的网络服务并将VNF集成到虚拟架构中，NFV编排器还能够验证并授权NFV基础设施（NFVI）的资源请求。
• VNF管理器能够管理VNF的生命周期
• VIM能够控制并管理NFV基础设施，包括了计算、存储和网络等资源。

为了使NFV MANO行之有效，它必须与现有系统中的应用程序接口（API）集成，以便跨多个网络域使用多厂商技术。同样，OSS/BSS也需要与MANO实现互操作。

主要的开源MANO项目有哪些？

1、ONAP

ONAP（开放网络自动化平台）是一个开源的软件平台，能够提供设计、创建、编排、监控和生命周期管理功能。ONAP项目的前身是AT&T主导的ECOMP项目和中国移动主导的Open-O项目，今年2月份这两个项目宣布合并成新的ONAP并置于Linux基金会的管理之下。

ONAP的主要运营商的主要成员包括AT&T、中国电信、中国移动、中国联通、Orange等等，厂商成员包括Juniper、思科，Cloudbase Solutions， 爱立信，GigaSpaces，华为，IBM，英特尔，Metaswitch，微软，H3C Technologies，诺基亚，Raisecom，Reliance Jio，Tech Mahindra，VMware，Wind River和中兴等等。

ONAP使用云技术和网络虚拟化提供服务，实现更快的开发和更高的运营自动化。它使服务提供商能够快速添加功能并降低运营成本，为服务提供商和企业更好地控制其网络服务，并使开发人员能够创建新的服务。最终，由于网络更好地适应，扩展和预测使得用户能够体验无缝连接。

（图为ONAP架构） 事实上，由于ONAP囊括了全球主要的运营商和众多的厂商，涵盖了全球超过50%的用户，其发展前景自该项目诞生以来就一直为业界所看好，但由于AT&T在ECOMP平台上有着超过800万行代码，且Open-O项目也有着数百万行的代码，项目的合并是一个旷日持久的过程。ONAP项目预计在今年11月份发布首个代码版本，届时将会把ECOMP的八个业务模块与Open-O的业务模块加以整合。

ONAP项目官网：https://www.onap.org/

2、OSM

OSM是ETSI领导下的由运营商驱动的开源MANO社区项目，旨在共同创新、创建并提供与ETSI NFV密切配合的MANO堆栈，OSM的愿景是提供满足商业NFV网络需求的生产环境的开源MANO堆栈。

从上图中我们可以看到OSM使用了OpenMANO（Telefonica发布的一个项目）和RIFT.io，以及OpenStack和Ubuntu JuJu。考虑到这些项目的重用，OSM得到电信公司（如Telefonica，英国电信，奥地利电信，韩国电信和Telenor）的支持，以及英特尔，Mirantis，RIFT.io，博科，戴尔，RADware等设备商的支持。

目前OSM已经发布了两个版本的代码，其官网是：https://osm.etsi.org/

3、OPNFV

OPNFV是一个开源项目，专注于加速NFV的发展，其目标是建立一个运营商级集成的开源参考平台，运营商、厂商成员将共同推进NFV的演进，确保多个开源组件之间的一致性、性能和互操作性。

OPNFV的工作范畴是构建NFV基础设施（NFVI），虚拟化基础架构管理（VIM），并将应用程序可编程接口（API）包括在其他NFV元素中，这些NFV元素一起构成了虚拟网络功能（VNF）和管理和网络编排（MANO）组件。OPNFV有望提高性能和功率效率;提高可靠性，可用性和可维护性。

目前OPNFV先后发布了Arno、Brahmaputra、Colorado、Danube四个版本，OPNFV项目能够很好的与上下游的开源项目紧密合作，共同促进NFV的发展和采用。

OPNFV官网：https://www.opnfv.org/

4、OpenStack Tacker

Tacker是OpenStack项目中的一个子项目，其目标是构建一个通用VNF管理器（VNFM）和一个NFV编排器（NFVO），以在NFV平台上部署和运行虚拟网络功能（VNF）。该项目是基于ETSI MANO架构，并使用VNF向端到端的编排网络服务提供全面的功能堆栈。

该项目脱胎于Neutron项目，在NFVO方面，该项目的目标是：

• 使用分解的VNF进行模块化端到端服务部署
• 确保VNF的有效设置并运行
• 使用SFC连接VNF
• VIM资源检测和资源分配
• 跨多个VIM和多站点（POP）编排VNF
  
  更多关于Tacker项目：https://wiki.openstack.org/wiki/Tacker

5、OpenBaton

Open Baton在管理和网络编排（MANO）上研究的时间比其他开源MANO组织出现的时间都要早，Open Baton由两个来自德国的研究机构Fraunhofer Fokus研究所和柏林技术大学领导的，Open Baton自2015年成立后，就专注于MANO代码的开发，而不是建立社区和关注市场本身。

与其他MANO组织不同的是，Open Baton并不是由运营商或者厂商参与的，而是由一些科研组织建立的，而且与其他的MANO组织并没有太多的交流。

Open Baton的MANO架构围绕着消息队列，提供了自由实现编排器逻辑和其他组件解耦。

Open Baton在欧洲的几个项目中得到了广泛的应用，一个是SoftFire，该项目使用NFV和SDN来创建可编程基础架构，第三方可以用它来开发新的服务和应用程序。此外，Open Baton是5G Berlin计划的主要组成部分之一。

OpenBaton官网：https://openbaton.github.io/index.html

6、OpenLSO

OpenLSO是MEF推出的促进服务编排生态系统的项目，能够综合使用符合MEF定义的LSO规范的开源解决方案和接口。OpenLSO主要针对希望加速采用MEF定义的LSO的服务提供商，以实现MEF定义的服务生命周期的功能齐全的端到端服务编排。

OpenLSO由MEF成员与开源服务协调解决方案市场领导者以及现有和新兴的开源项目（如ON.Lab和Open-O）紧密合作运营。 OpenLSO通过LSO Reference Point与LSO Presto和OpenCS进行交互。

更多OpenLSO信息：https://wiki.mef.net/display/CESG/OpenLSO

7、OpenMANO

OpenMANO是Telefónica推出的开源项目，提供了目前在ETSI NFV ISG标准下的管理和编排（NFV MANO）参考架构的实现，该项目可以轻松创建和部署复杂的网络场景，并通过实验室中涉及的多个VNF成功验证。

Telefónica通过发布开源代码来推动OpenMANO的应用，从而鼓励业界和软件开发人员从现实条件下彻底验证、精心设计和分层架构，探索NFV的无限可能。

OpenMANO是NFV-O（网络功能虚拟化编排器）的参考实现。它通过其API与NFV VIM接口，并提供基于REST（OpenMANO API）的北向接口，其中提供NFV服务，包括VNF模板，VNF实例，网络服务模板和网络服务实例的创建和删除。

截至今天，OpenMANO是一个非常基本的实现，不适合商业部署。更多OpenMANO信息：https://github.com/nfvlabs/openmano

其他的MANO项目如下：

• Cloudify Telecom Edition——旨在提供全套的NFV MANO，为NFV编排和VNF管理提供服务
• Gohan——由NTT Data创建和维护的SDN和NFV业务流程的开源服务开发引擎
• Tata Telco Cloud——由Tata公司主导提供开放的VNF管理，以在OpenStack平台上启用NFV服务编排的项目
• RIFT.io在8月的英特尔开发者论坛上向全世界推出了RIFT.ware，并在2015年年底向开源社区宣称发布了RIFT.ware 4.0（一种用于NFV管理和编排的完整解决方案）
• Ubuntu Juju：Canonical的Juju是开源的通用VNF管理器。但是，它更多的是服务建模系统，其中服务，相互关系和规模可以建模。

MANO的使用状况

在今年上半年SDxCentral发布的NFV调查报告中（2017 NFV Report Series Part 2: Orchestrating NFV – MANO and Service Assurance.），26%的受访者表示不会采用开源MANO，只会选择商用的MANO解决方案。

49%的受访者表示，一旦时机成熟将会考虑采用开源MANO的解决方案。受访者中表示正在考虑开源MANO的人中，19%来自Open Source MANO (OSM)，这些受访者中13%表示正在考虑Open-O的软件，12%的用户正在考虑Tacker，9%的受访者关注其他的开源产品。

随着NFV的采用率不断增长，NFV已经成为一个革命性的运营和服务构建模式，并且已经成长为蓬勃发展的市场，各种规模的企业、运营商纷纷向NFV MANO倾注更多的心力。

服务提供商寻求在现有OSS系统和新的NFV管理和编排（MANO）系统之间实现虚拟化基础设施的协调，软件厂商将自己定位于MANO和传统OSS之上的总体编排层，硬件厂商正在开发MANO解决方案，并试图向上迁移堆栈。可以预见的是MANO必将成为NFV崛起的基石，并且在NFV的发展壮大中发挥越来越重要的作用。

原文链接

http://www.sdnlab.com/19794.html