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