101平衡模式
传输方式分为非平衡方式和平衡方式传输两种：
1.非平衡方式传输：只有主站启动各种链路传输服务，子站只有当主站请求时才传输。这种传输方式对于所有网络结构都可适用。但是在点对点和多点对点的网络结构中，非平衡方式传输没有充分发挥这种网络的内在潜力。
2.平衡方式传输：主站和子站可以同时启动链路传输服务，所以必须有一对全双工的通道。
这里规定对于点对点和多点对点的网络结构采用平衡方式传输，对于多点共线、多点环形和多点星形的网络结构采用非平衡方式传输。
非平衡是表示通讯双方一主一从关系（一个询问，一个应答），报文发送方向通过PRM识别；平衡是表示双方没有主从关系，是对等关系，报文发送方向通过PRM识别，双方都可以发起询问(命令)，也能应答对方发起方报文PRM=1，响应方报文PRM=0，大多情况下用的都是非平衡传输规则，平衡传输规则很少见。
在非平衡模式中PRM决定了报文传送的方向，PRM=1表示主站向子站传输报文，PRM=0表示子站向主站传输报文；
DIR=1表示由子站发出的上行报文，DIR=0表示主站下发的下行报文；
在两个等同的站(即两个控制中心)由协商确定DIR位的定义。
像之前的介绍一样“平衡模式是表示双方没有主从关系，是对等关系”,也就是说在传输过程中主站可以主动发送数据，从站也可以主动发起数据，但是主从站的关系是设备在使用时就确定好的，比如说我们现在要做的是一个馈线终端的101规约，那么这个设备肯定是作为从站来使用，协议自然是从站的编写方式，在回复主站时DIR=1（两个控制中心的DIR是由协商决定的）；而PRM是决定发送的方向，不管主站或者从站PRM的值都可以是1，这里的“1”表示报文数据是从哪里启动的。
报文功能码的解析需要根据两种模式下的方式进行解析。
平衡模式的控制域与非平衡模式的控制域的功能码是有区别的，如下图：
启动方向的功能码和服务 从动方向所允许的功能码和服务
<0> 复位远方链路 <0>确认: 认可或者
<1>确认: 否定认卟
<1> 复位用户进程 <0>确认: 认可或者
<1>确认: 否定认可
<3> 发送/确认 链路测试功能 <0>确认: 认可或者
<1>确认: 否定认可
<4> 发送/无回答 无回答
<9> 请求/响应 请求链路状态 <11>响应: 链路状态
图1平衡模式
|
启动方向的功能码和服务 |
从动方向所允许的功能码和服务 |
|
<0> 复位远方链路 |
<0>确认: 认可或者 <1>确认: 否定认可 |
|
<1> 复位用户进程 |
<0>确认: 认可或者 <1>确认: 否定认可 |
|
<3> 发送/确认用户数据 |
<0>确认: 认可或者 <1>确认: 否定认可 |
|
<4> 发送/无回答 |
无回答 |
|
<8> 请求访问要求 |
<11>响应: 链路状态 |
|
<9> 请求/响应 请求链路状态 |
<11>响应: 链路状态 |
|
<10> 请求/响应 请求1级用户数据 |
<8>响应: 用户数据或者 <9>响应: 无所请求的用户数据 |
|
<11> 请求/响应 请求2级用户数据 |
<8>响应: 用户数据或者 <9>响应: 无所请求的用户数据 |
图2 非平衡模式
平衡模式下的报文实例：
18-14:54:27.954 send:10 49 01 00 4a 16 //49 0100 9 请求链路状态
18-14:54:28.924 recv:10 8b 01 00 8c 16 //8b 1000 b 响应链路状态
18-14:54:29.167 send:10 40 01 00 41 16 //40 0100 0 复位链路
18-14:54:30.138 recv:10 80 01 00 81 16 //80 1000 0 确认
18-14:54:30.218 recv:10 c9 01 00 ca 16 //c9 1100 9 请求链路
18-14:54:30.380 send:10 0b 01 00 0c 16 //0b 0000 b 响应链路状态
68 0b 0b 68 73 01 00 64 01 06 01 00 00 00 14 f4 16 //73 0111 3 发送数据 总召唤
18-14:54:31.514 recv:10 c0 01 00 c1 16 //c0 1100 0 确认(响应链路状态)
10 80 01 00 81 16 //80 1000 0 确认(总召唤)
18-14:54:31.675 send:10 00 01 00 01 16 //00 0000 0 确认
18-14:54:32.727 recv:
68 0b 0b 68 f3 01 00 46 01 04 01 00 00 00 00 40 16 //f3 1111 3 发送数据 70 响应总召唤
18-14:54:32.889 send:10 00 01 00 01 16 //00 0000 0 确认
18-14:54:33.940 recv:
68 0b 0b 68 d3 01 00 64 01 07 01 //d3 1101 3 发送数据
18-14:54:34.021 recv:00 00 00 14 55 16 //
18-14:54:34.102 send:10 00 01 00 01 16 //00 0000 0 确认