TR-069的交互(其一 流程简述）

TR-069交互流程的简单展示

从这里开始，我会简单介绍TR-069的交互内容。（注意，本文为了让大家在大脑中对TR-069的交互有一个初步的印象，所以会通过场景举例以及对过程进行一些粗糙的划分来进行展示，方便大家学习。但随着后面更加深入的介绍，这个交互流程会变得更加复杂，本文的部分概念可能需要大家进行转变。）

首先我们先看看下方的宽带论坛官方给出的TR-069交互示例图。

CPE和ACS的每次交互里，包含了上半边HTTP的Post和Response和下半边XML的交互(Inform，GetParameterValues等)。

图1 - TR-069交互示例图（选自TR-069官方文档） 

交互过程的典型场景：

这里为了方便理解这些交互的流程，我根据发起连接的主动方，举两个典型的交互场景例子：

1. CPE主动连接ACS

2. ACS对CPE下发命令

CPE主动连接ACS

下图是一个CPE主动连接ACS的HTTP/XML流程。（XML格式的报文以红字表示）

我们可以把它当成是一个与人相识的过程，CPE端通过Inform报文向ACS端上报自己的信息，而ACS则会返回Inform Response，在信息上报结束后双方会以204 No Content结束基本的会话流程。(当然，实际的会话结束是在TCP交互，这里不作赘述)

需要注意的是，Inform(附账号密码)这一项里，账号密码并不包含在XML报文中，而是在HTTP报文里提供，详细的内容会在后面篇章里进行说明。

图2 - CPE主动连接ACS交互示例图 

Inform报文里往往会携带一些CPE的基本信息，但是具体携带哪些信息，TR-069标准中并未给出明确的定义，因此往往由CPE的供应商来决定。

图3 - Inform报文简单介绍 

ACS对CPE下发命令

下图是ACS对CPE下发命令的HTTP/XML流程。（XML格式的报文以红字表示）

我们可以把它看成一个找人帮忙的过程了，ACS发送GET请求到CPE，而后CPE发送Inform进行交互，然后ACS便下发SetParameterValues命令请CPE执行，CPE执行后返回Response。ACS若此时没有其他命令，则双方会以204 No Content结束本次交互。

图4 - ACS对CPE下发命令交互示例图

交互过程的进一步解读

你发现了吗？这两个交互过程中，都会出现CPE发送Inform向ACS提供基本信息的内容。

图5 - 典型场景共通点标注

实际上这是TR-069标准里定义的要求："A CPE MUST call the Inform method to initiate a transaction sequence whenever a Session with an ACS is established“

也就是说，CPE要和ACS开始进行交互，首先必然会经过Inform的过程。这也是一个TR-069交互开始的标志。类似SetParameterValues这样的下发命令，需要经过Inform后TR-069交互建立，才能开始进行。

我们这里延伸一下：那么CPE主动连接ACS的时候，ACS能否在回复Inform后即刻就下发命令呢？

答案是可以的，我也顺带把这种交互画了出来。

图6 - CPE主动连接ACS时ACS下发命令交互示例图

有的人可能会问了，那这种场景下，是不是说上面的POST被SetParameterValues Response取代了呢？

Emmm，其实SetParameterValues Response的这个XML报文，它是夹在HTTP POST报文里的。

图7 - SetParameterResponse报文示例图

交互过程的划分

因此，我们其实是可以把整个TR-069交互划分成三步来看：

通告部分

CPE发送Inform，ACS回复Inform Response，双方进行初步交互。

命令下发部分

ACS下发命令，CPE执行命令并回复对应的Response。

会话关闭部分

交互完成之后，双方关闭会话。

回到最上面的官方示例图，我们可以将这三个部分标识出来：

图8 - TR-069交互示例图的过程划分

注意点

如开头所说，随着后面技术学习的深入，大家会发现，这些交互过程并不能简单地划分成几个部分去考虑，其中包含着各种各样的RPC Method，以及TCP的握手挥手。

但对于刚接触TR-069的同行来说，使用这样的过程划分主要是方便各位对交互有一个简单笼统的印象，方便在一开始接触相关问题排障时能够更有方向性。如果描述中存在可以优化改善的地方，也希望大家多提意见~(也多多点赞收藏哈~~)