|
目录
摘要
在使用Dialogic® NetStructure®SS7组件的SS7环境中，为了实现"5个9"的可用性和提高容错能力，可以将一个SS7端结点扩展在两个机箱上。通过将SS7节点部署于多个机箱之上可以将信令点的功能分离，进而将多机箱内的硬件处理器相互独立出来，由此在一个处理器发生故障的情况下，另外一个处理器还能够继续工作，整个系统还可以正常运行。
Dialogic网擎SS7组件就是专为这种双处理器方法而设计的，它提供了一种可将一个点代码分散到两个主动SS7协议引擎上的架构。使用这种技术，只要在分离的两个机箱中同时安装Dialogic网擎SS7信令卡，一个SS7链路集内的链路就可以分散到这两个机箱中处理。这种双机箱方法可带来高可用性和出色的容错能力，本文将探讨这种双机箱方案的设计与实施。
介绍
因为公共电话网用户对于服务可靠性的期望日益增高，因而设备生产商和系统集成商提出了高容错能力和高可用性要求，即通常所说的'五个9'可用性（要求系统在99.999%的时间都可以工作）。
这种系统应在部分硬件或软件发生故障时，也能够继续提供服务。当通信网中的信令组件发生故障时，有许多众所周知的方法来保证系统继续工作：
- 到每个端结点建立多条信令通路（SS7链路和链路集）
- 通过独立的接口和电缆来分配这些信道
- 将单个信令点的SS7终端处理分配到单个机箱内的多个处理板卡上进行处理
- 物理隔离和复制针对单个信令点的SS7接口（Dialogic® NetStructure®SIU和SS7板卡）
- 在两个机箱之间划分信令点的功能，包括应用层（本文的主题）。
上面所列的前3个方案可以通过在两个相邻的交互点之间部署多条链路（64或56Kbps）来实现（根据定义，这些链接将全部放在同一个链路集中）。最后两个方案可以通过在两个机箱内采用两个独立但互相协作的SS7协议栈来完成。这两个机箱通常情况下是分开的，但可以通过互连来提供更高的故障恢复能力。
图表（图1）描述了双容错系统协议间的关系。
多个机箱上部署一个SS7信令点
在多个机箱上部署一个SS7信令点，将正常的处理器与另一个故障的处理器隔离开，使整个系统在一个组件处理器或机箱完全故障的情况下可以继续工作。与通用的故障恢复架构相同，有许多方法可以实现这种设置，每种方法均有其各自的优缺点。
Dialogic® NetStructure®SS7信令板卡采用一个2N通道并且能够将点代码分布在两个主动SS7协议引擎上。这样就允许一个SS7链路集中的链路分布在两个独立的机箱中，并且每个机箱中都安装了SS7信令卡。
系统的两部分之间需要提供两条通信路径，一条在MTP层，使用MTP2数据链路作为传输协议，另一条在第4层或User
Part层，在两部分的第4层协议之间传送进程间讯息。第二条通路通常通过使用Dialogic提供的TCP/IP
Ethernet和RSI（容错接口，Resilient Socket Interface）软件来完成。这种组合提供了一个SS7接口，协议处理分散在两个机箱中进行。这两个机箱在物理上是独立，在网络上却像一个整体。
同时还需要考虑维护状态信息，并且检测应用层的指示，这些内容在本文的后面部分讨论。
概念
双MTP3概念
为了使运行在分散硬件上的双MTP3处理能够维护状态信息并且（在某种路由状态下）有选择地交换发送讯息，需要在两个系统之间建立一个特殊的链路集作为单点代码进行工作。图2显示了这样一个系统的路由情况，包括两部分，A和B，处于MTP3层。
正常运行状态下，可用的链路在MTP A和MTP B之间平均分配。MTP A从本地SS7协议的第4层（User
part）接收到的讯息在与相邻节点相连的链路上发送。同样，MTP B接收到的讯息也从本身与相邻节点的链路发送。
当连接到MTP A或连接到 MTP B的所有链路均发生故障时，讯息通过MTP A和MTP
B之间的链路集发送到其它MTP，并由该MTP在可用的链路上重新发送。参见图3。
MTP A和MTP B之间的链路集的设置方法与任何其它SS7链路和链路集相同。如果有额外的数据设置表明此链路与其它连接相邻节点的链路不同，则应区别对待。
每个MTP接收的讯息总是传送到'本地'第4层协议上。假设本地User Part总是可用的。
MTP上的状态机
SS7协议的第4层为每一呼叫或事务处理维护状态信息。有两种可能的方法：一种方法是将状态信息复制到组成信令点的N个系统中，第二种方法是分割数据，使每一半状态数据存贮在系统的对应部分中，而这样任何一个子架发生故障都会使系统容量减少1/N。
第一种方法需要一个在容错系统的N个组件间复制状态数据的可靠方法。如果这N个系统使用大量CPU时钟来同步，则这种方法效率非常低。
因为复制过程中故障可能发生在任何点，很难保证所有的系统都包含相同的数据，所以这里采用第二种（2N）方法。
双电话操作（基于CIC）
一个SS7系统使用ISUP、TUP或其他国家电话第4层电路交换控制协议，可以通过分离两个物理实体（可以是同一机箱中或两个独立机箱的两套板卡）之间的电路终端（每个电路有OPC、DPC和CIC组合唯一标识）来实现容错。尽管对于处理SS7和媒介的两套板卡可以使用相同的方法，但下面的描述仍然讨论两个机箱的情况。
一个双ISUP/TUP系统通过激活每个机箱中的一半电路协议状态机进行工作。每个ISUP/TUP层通过本地MTP3发送所有的传送流量。本地MTP3采用与相邻SS7节点之间的本地链路进行传输，如果该链路发生故障，则采用机箱之间的SS7链路。
远程SS7端结点不用与任何连接到任一机箱的SS7链路共享负荷；因此，不能保证一个机箱接收的讯息可以加载到连接于另一个机箱的电路上。为了解决这个问题，ISUP/TUP层预检测每个接收讯息中的CIC，以判断设置中是否记录了该电路。如果没有，则将接收的讯息发送（象一个MTP3传送指示）到负责处理未知电路讯息的任务中。在一个双ISUP/TUP系统中，这个任务由第二个机箱中运行的第二套ISUP/TUP协议进行处理。讯息被标记为由一个ISUP/TUP拒接的讯息。因此如果第二个ISUP/TUP协议不能识别电路，则这个讯息将作为来自未知电路的讯息依照ISUP/TUP协议来处理。因此在这种情况下，如果两个系统都不识别该信息，就可以防止该信息在系统间不停的传来传去。
此过程如图4所示。
尽管RSI和TCP/IP方法可能是最简单的，但是讯息本身通过一个依赖于应用程序的机制从一个系统传送到另一个系统。
SIU通过使用以太网从媒介处理中分离SS7接口来处理容错问题，两个SIU作为一个点代码进行容错，如图5所示。通过分离SS7接口，SIU也允许系统最多可以由32个处理语音电路（媒介）的应用节点组成。
双SCCP问题（子系统状态管理）
SCCP通过支持可寻址子系统概念提高了讯息传递部分（MTP）的路由能力。所有已知的本地和远程子系统的路由可用性（允许状态或禁止状态）在SCCP层中进行管理。
在一个由N个SCCP层（或多个SCCP例程）组成作为同一点代码的系统中，用户应用和远程端结点需要能够通过任何SCCP例程交换SCCP数据讯息，并且希望每个SCCP中的路由表都是相同的。为了达到这个目的，需要使用广播机制增强SCCP层，这种机制将本地或远程的路由状态的任何改变发送到广播任务。广播任务负责将路由变化传送到N－1（其它）SCCP例程。在一个双系统中，广播任务只是另一个SCCP层，这两层使用基于讯息的API进行通信。在一个双机箱/子架环境中，这些讯息可以由RSI和TCP/IP以太网组合来传递。
SCCP总是将接收指示传递给同一机箱的SCCP用户任务。参见图6。
双TCAP操作
TCAP层的2N配置与2N ISUP/TUP协议的操作方法相同。系统管理的事务在两个TCAP层之间平均分配，每个TCAP层管理一半事务的状态和传送组件。每个事务永远只属于一个TCAP。对于由本地TCAP用户初始化的事务，它属于接收第一个用户传送数据要求的TCAP。对于由远程TCAP实体初始化的事务，此事务属于从SCCP层接收第一个事务讯息的TCAP协议（BEGIN或QUERY）。因此，远程初始化事务的负荷分担由SS7网络如何在连接系统两部分的SS7链路之间分配第一个TCAP讯息（BEGIN或QUERY）来定义。
为了允许快速识别每个接收讯息都拥有该事务状态机的TCAP，在一个mN系统中，每个TCAP协议都拥有一个唯一的逻辑标识值或例程值（一个数字）。以原始事务id的方式为每一个发送讯息编号，并且在来自远程TCAP实体的每一个目标事务id响应中加以反映。
除了BEGIN或QUERY以外，所有TCAP层对于任何讯息的接收处理都是通过恢复事务id的例程bit开始，由此来快速确定此讯息是否正在由正确的TCAP处理（该TCAP拥有针对此事务的激活的状态机）。如果不是，讯息恢复操作退出，将此讯息传递给处理该例程讯息的模块，如图7所示。
图7 双TCAP操作
另一TCAP协议的模块标识符使用TCP_MSG_S_TCI讯息进行配置，此讯息使用两个参数：TCAP
instance和module_id。（此讯息将在附录A中详细介绍）。对于A方，本地TCAP例程是0，远程TCAP例程是1；因此，此讯息应该用来设置远程TCAP的module_id，例程1的module_id为0x34。在B方，本地TCAP例程是1，TCP_MSG_S_TCI_ID讯息应该用来设置例程0（从B方视为远程TCAP），其module_id为0x24。
每个TCAP将所有接收的信息传递到同机箱中的TCAP用户任务中。根据每一个TCAP中不同的应用层或用户，将TCAP层的本地应用程序发送的传送会话和组件原语传递给正确的TCAP。在双系统环境中，接收讯息可以在任何MTP和SCCP层上共享；因此，一个TCAP层接收由其它TCAP处理的应用在激活事务上的TCAP讯息是可能的。
TCAP用户（GSM-MAP、IS41-MAP、INAP）
TCAP用户，如GSM-MAP、IS41和INAP等，与它们使用的TCAP层紧密地结合。在一个多TCAP系统中，TCAP用户之间共享事务，在双TCAP系统中平均分配。在TCAP层完成了接受到的讯息针对相应TCAP状态机的处理；因此，在TCAP用户层不需要额外的处理。参见图8。
配置
面向Linux V2.00和Windows V2.00的Dialogic开发包支持双机箱SS7系统配置，并且提供了设置双系统操作MTP、ISUP、TUP和NUP层的必要命令和参数。SCCP、TCAP和TCAP-User层的配置与单（无容错）系统的配置方式完全相同――使用离散的讯息，既可以将此功能嵌入用户自己的程序中，也可以使用s7_play实体。
在双机箱系统中，为了配置的目的，应将两个部分分开对待，每个部分都有独立的配置文件。
MTP3的配置
在双MTP系统中，一个链路集内的链路应该在两个系统间平均分配。两部分的逻辑参考参数（如link_id和linkset_id）都应该从0开始。系统每部分的链路和链路集都使用相同范围的标识符（标记符/句柄）。
需要使用一条额外的链路集来连接两个MTP3平台，以使单个点代码可以在两个平台间共享。与标准SS7链路集的定义方式相同，使用MTP_LINKSET配置命令，并且 和使用相同的值（均设置为两个平台间共享的平台点代码的值）。这个链路集需要将参数的bit
15设置为1，表明此链路集连接两个使用相同点代码的MTP3协议。链路通过MTP_LINK命令添加到链路集。
每一目标路由（包括相邻节点）都应该指明两个链路集。主要的是连接本地MTP到相邻节点的链路集的标识符。参数应该用来表示连接共享一个本地点代码的两个MTP3层的链路集。参数应该设为0x0001，表明第二个链路集已经被指定，并且只有在通过主要链路集无法路由到目标节点的情况下，才可使用这个链路集来路由传输流量。所有其它参数的含义都与用户手册中描述的单MTP设置中的参数相同。
对于MTP A：
对于MTP B：
注意：这些不包括任何设置或定义信令板卡的命令，应该象定义标准的非双系统一样定义。 MTP_ROUTE
参数针对ISUP而设置，在上例中用户部分SI=5。
对于MTP A：
MTP_CONFIG 0 0 0x0000
MTP_LINKSET 0 300 1 0x8000 300 0x8
MTP_LINKSET 1 400 1 0x0000 300 0x8
MTP_LINK 0 0 0 0 0 1 0 0 0x4006
MTP_LINK 1 1 0 0 0 0 16 16 0x0006
MTP_ROUTE 300 0 0x0020
MTP_ROUTE 400 1 0x0020 0x0001 0
MTP_ROUTE 600 1 0x0020 0x0001 0
对于MTP B：
MTP_CONFIG 0 0 0x0000
MTP_LINKSET 0 300 1 0x8000 300 0x8
MTP_LINKSET 1 500 1 0x0000 300 0x8
MTP_LINK 0 0 0 0 0 1 0 0 0x6006
MTP_LINK 1 1 0 1 0 0 16 16 0x0006
MTP_ROUTE 300 0 0x0020
MTP_ROUTE 500 1 0x0020 0x0001 0
MTP_ROUTE 600 1 0x0020 0x0001 0
连接两个MTP3层的链路集应该提供足够的链路，以带来足够的信令带宽，从而允许一个MTP3的所有流量都可以通过第二个MTP3路由。设计者也应该注意，为了使每个MTP3可以传送另一个MTP3的流量，系统的每一部分在正常工作情况下的负荷不应超过50%（所有的处理和信令通道带宽）。SS7系统通常的最大负荷为20~40%。
机箱间链路的激活方式必须同连接平台和远程SS7节点的其它链路的激活方式相同。这可以通过使用mtpsl工具或通过从应用程序传送MTP链路或链路集激活命令讯息来实现。
ISUP和TUP的配置
对于ISUP，其它ISUP协议（其它系统中）的module_id通过设置ISUP_CONFIG命令中的可选 参数来指定。应该设置ISUP_CONFIG的选项位ISPF_DUAL，表明ISUP应该将从MTP3接收的任何未知电路实体的讯息传送到这个软件任务。
同样，对于TUP，TUP_CONFIG的应该设置为第二个机箱中TUP模块的module_id，并且设置TUPF_DUAL选项位。通常情况下ISUP的任务标识符设置为0x23。对于发送未知电路ISUP讯息的任务，A方的标识符为0x73，B方的标识符为0x63。通常分配给TUP的任务标识符为0x4a。对于发送未知电路TUP讯息的任务，A方的标识符为0x93，B方的标识符为0x83。用户应该设置一个LOCAL任务，以便将发送到这个任务的讯息传送到另一个平台上的ISUP或TUP协议层。这可以通过使用RSI任务和REDIRECTION命令（稍后介绍）来轻松实现。
注：Dialogic® NetStructure®CPM8、SPCI2S或SPCI4板卡上运行ISUP和TUP。
当ISUP或TUP协议在Dialogic网擎SS7板卡上运行时，B方SEPTEL_CP命令的l1_flags参数必须设置为包括bit
9（0x0200）。
下面的例子说明了ISUP和TUP配置命令：
A方
* 配置ISUP模块：
* ISUP_CONFIG
[]
ISUP_CONFIG 0 0 0 0x0435 4 64 0x73
*
* 设置TUP参数：
* TUP_CONFIG
[]
TUP_CONFIG 0 0 0 0x8141 4 64 0x93
*
B方
* 配置ISUP模块：
* ISUP_CONFIG
[]
ISUP_CONFIG 0 0 0 0x0435 4 64 0x63
*
* 设置TUP参数：
* TUP_CONFIG
[]
TUP_CONFIG 0 0 0 0x8141 4 64 0x83
*
两个系统中的电路组既可以从0开始编号，也可以两个系统间隔标号。如果使用第一种方法，整个系统的容量就是单ISUP/TUP协议层系统容量的2倍；如果使用第二种方法，系统总容量与单ISUP/TUP协议层系统的容量相同。对于这两种情况，每半部分控制独立的CIC范围，如图11和12所示。
系统两部分之间没有重复电路组（"单容量"系统，如图12所示）的系统在一部分故障的情况下能够激活（配置）另一部分没有使用的电路组。这个过程可以使用xxx_MSG_CNF_GRP讯息配置电路组来实现。由此可以为另一单元中失效的电路提供SS7信令资源以及ISUP或TUP状态机。但是，如果电路终端本身仍然同故障单元物理上相连，那么信令能够为这些电路实现的唯一进程就是硬件阻塞。
SCCP的配置
在SCCP层，每个SCCP协议的配置都应该使用相同的本地子系统、远程信令点和远程子系统数据。
smb_id配置参数用于识别状态更新时的目标节点，并且应该设置为一个任务的id。这个任务能够在双系统中将这一信息传递给其它SCCP模块。在大多数情况下，SCCP使用0x33作为任务标识符，并且smb_id在A方应该设置为0x53，在B方应该设置为0x43。可以使用system.txt文件中的一个REDIRECTION语句来将这些讯息路由到RSI或相似的任务，以便将其传递到通过以太网连接的其它SCCP层。此外，SCCP
smb_flags配置参数应设置为0x001c。
TCAP的配置
在一个多TCAP环境中，每一TCAP具有一个唯一的例程，它是在SCCP边缘使用事务id编码的，这样可以为接收讯息快速分析正确的目标TCAP。第一个TCAP例程值通常应该为0，下一个为1。
tid_ninst参数控制使用事务id中的多少位对例程数据进行编码。在一个双系统中，1位就可以区分两个TCAP。（注意tid_ndref必须足够大，可以对最高的dialogue_id值进行编码。在一个同时支持2048个对话的系统中，tid_ndref的值必须大于等于11}。
两个TCAP部分的逻辑dialogue_id的范围可以相同（这样运行在这两个系统上的两个应用进程将在相同的dialogue_id范围内工作），也可以使用不同的范围。
机箱间的通信
容错接口（RSI）软件从它的输入队列中获取具有目标节点的讯息，而不获取RSI本身的讯息，并且将这些讯息发送给TCP/IP以太网远程端的同等RSI任务。通信采用TCP/IP套接字，一端作为服务器，另一端作为客户端。
在接收端，RSI获取从以太网接收的讯息，并且将它们通过本地讯息传输系统传递到原始讯息目标所标识的任务中（帧头dst字段）。如果两个RSI任务通过以太网进行的通信发生故障，传递到RSI通过以太网进行发送的讯息将被丢弃。
系统中运行的两个RSI任务（每半个系统一个）使用相同的唯一的模块id，通常为0xb0。这必须在带有LOCAL定义的两个系统的system.txt文件中加以声明，使用FORK_PROCESS命令开始。RSI程序将其模块id作为可选的命令行参数，前缀为'-m'。例如：
./rsi -m0xb0
任何发送到使用指定模块id的RSI的讯息都会由本地RSI任务进行处理，并且不会通过以太网传输。
主机与每个从机间的RSI连接使用rsicmd工具激活。rsicmd工具的用法如下：
rsicmd
[]
是这个特殊信道的逻辑标识符。RSI通过匹配讯息例程值（由GCT_set_instance设置，缺省值为0）和link_id值来选择输出通道。对于大多数的双系统，两个系统之间建立一条RSI连接就足够了，因此这个参数应该设为0。
指定一个模块id，当指定的RSI连接失效时，此模块id将收到通知（一个讯息）。这个参数的设置可以将这些指示传递给应用任务或者本地管理事件查看程序，如s7_log等。
和应该依据下表进行设置：
| 连接类型 |
rem_addr |
ink_type值 |
| 服务器 |
B方的IP地址 |
0（客户端） |
| 客户端 |
0 |
1（服务器） |
系统的一端需要设置为客户端，另一端设置为服务器。
指定了连接所使用的TCP/IP套接字端口号。每个RSI连接（应该具有唯一的link_id）必须使用唯一的端口号，从9000开始。
是可选的，指定了传送讯息的RSI模块。
对于所有可以通过RSI连接（与系统另半部分相连）访问的目标节点，system.txt文件中必须插入一条REDIRECT语句（第二个ISUP、TUP、SCCP和/或TCAP协议的module_id值）。
例如，一个双ISUP系统应该由两个ISUP部分组成，每部分缺省module_id都为0x23。A方ISUP的配置数据表示另一个ISUP部分的module_id为0x73；因此，在A方将会有一个重定向的动作来对经过RSI发送往0x73的任何讯息重新定向。在B方，应该有一个REDIRECT语句将B方RSI所接收的所有目标为0x73的讯息路由到本地ISUP，标识为0x23。具体情况如图13所示。
运行在信令卡上的协议模块，接收端（对方）的REDIRECT语句应该通过ssd或ssds驱动（通常情况下module_id为0x20）来对讯息进行重定向，如图14所示。
下表给出了系统双方都应该使用的module_id值。
| 模块 |
A方设置 |
B方设置 |
| 本地ISUP |
0x23 |
0x23 |
| 对方ISUP |
0x73 |
0x63 |
| 本地TUP |
0x4a |
0x4a |
| 对方TUP |
0x93 |
0x83 |
| 本地SCCP |
0x33 |
0x33 |
| 对方SCCP |
0x53 |
0x43 |
| 本地TCAP |
0x14 |
0x14 |
| 对方TCAP |
0x34 |
0x24 |
| 本地MAP |
0x15 |
0x15 |
| 本地IS41 |
0x25 |
0x25 |
| 本地INAP |
0x35 |
0x35 |
对于容错应用的考虑
在一个SS7接口中嵌有应用的双系统中，应用或者SS7组件故障将导致该部分系统完全瘫痪。
在一个双电路交换应用（使用ISUP或TUP）中，物理电路终端分布在组成系统的两个机箱中，因此如果系统的一部分发生故障，将导致一部分电路的物理故障。在SS7终端，硬件故障通常通过发送硬件阻塞（也称为硬件隔离）来处理。这样所有受这部分硬件影响的当前呼叫都会被拆除，表示这些电路不能被选择用于呼叫，直到硬件隔离解除。如果电路故障恢复，则硬件隔离即会被解除。
但是，在前面所述的配置中，系统继续工作的部分对于故障电路一无所知（这部分配置数据保存在故障的部分中），因此不能发送硬件隔离命令。解决这个问题的一个办法就是配置电路组，这样可以为另一部分的电路组保留空间。当一个电路组发生故障时，这些备份的电路组可以由继续工作的部分进行配置，允许向与故障机箱物理连接的电路发送硬件隔离命令。
也可以采用物理上隔离应用媒介/电路处理和SS7协议状态信息，使两个应用程序可以利用两个SS7接口进行通信（SIU采用这种方法）。物理隔离可以采用RSI和以太网来实现。
如果需要，应用可以通过使用基于讯息的API和RSI/以太网进行通信，来在节点间进行互相检查以检测故障。定义用户具体信息必须出于这个目的。
在一个双TCAP系统中，系统的一部分故障会导致TCAP状态信息的丢失（例如，事务状态和任何尚待传输的存储部件）。在智能网络环境中，如果可能，此事务相关的呼叫将被拆除。在移动/无线环境中，任何相关的挂起的移动服务（例如短讯息）都可能超时，操作将报告为出现故障。这些操作应该在系统继续工作的部分中再次执行。
与SS7协议进行通信的应用必须在逻辑电路id和每个SS7预先配置的会话id范围内工作。系统的两部分既可以使用相同范围值，这些值只在每部分内部使用，也可以在不同的范围内运行。
设置System.txt值
下图展示了一个双ISUP/TUP/SCCP/TCAP系统中各模块之间的关系，以及系统两部分的config.txt文件中的相应条目。参见图15。
主机协议的System.txt
A方
REDIRECT 0x34 0xb0 * TCAP to chassis B
REDIRECT 0x53 0xb0 * SCCP to chassis B
REDIRECT 0x73 0xb0 * ISUP to chassis B
REDIRECT 0x93 0xb0 * TUP to chassis B
*
REDIRECT 0x24 0x14 * TCAP from chassis B
REDIRECT 0x43 0x33 * SCCP from chassis B
REDIRECT 0x63 0x23 * ISUP from chassis B
REDIRECT 0x83 0x4a * TUP from chassis B
B方
REDIRECT 0x24 0xb0 * TCAP to chassis A
REDIRECT 0x43 0xb0 * SCCP to chassis A
REDIRECT 0x63 0xb0 * ISUP to chassis A
REDIRECT 0x83 0xb0 * TUP to chassis A
*
REDIRECT 0x34 0x14 * TCAP from chassis A
REDIRECT 0x53 0x33 * SCCP from chassis A
REDIRECT 0x73 0x23 * ISUP from chassis A
REDIRECT 0x93 0x4a * TUP from chassis A
system.txt文件必须也包括主机上运行的所有本地SS7协议，如ISUP、TUP、SCCP或TCAP（如果有），以及应用程序任务、配置工具（如s7_mgt）和调试工具的LOCAL定义。这里也应该通过FORK_PROCESS语句来启动相应的驱动和支持任务，在相应的程序员手册中有详细描述。
信令处理器板卡协议的System.txt
A方
REDIRECT 0x34 0xb0 * TCAP to chassis B
REDIRECT 0x53 0xb0 * SCCP to chassis B
REDIRECT 0x73 0xb0 * ISUP to chassis B
REDIRECT 0x93 0xb0 * TUP to chassis B
*
REDIRECT 0x24 0x20 * TCAP from chassis B through
ssd
REDIRECT 0x43 0x20 * SCCP from chassis B through
ssd
REDIRECT 0x63 0x20 * ISUP from chassis B through
ssd
REDIRECT 0x83 0x20 * TUP from chassis B through
ssd
B方
REDIRECT 0x24 0xb0 * TCAP to chassis A
REDIRECT 0x43 0xb0 * SCCP to chassis A
REDIRECT 0x63 0xb0 * ISUP to chassis A
REDIRECT 0x83 0xb0 * TUP to chassis A
*
REDIRECT 0x34 0x20 * TCAP from chassis A through
ssd
REDIRECT 0x53 0x20 * SCCP from chassis A through
ssd
REDIRECT 0x73 0x20 * ISUP from chassis A through
ssd
REDIRECT 0x93 0x20 * TUP from chassis A through
ssd
system.txt文件也必须包括所有应用程序任务、配置工具（如s7_mgt）和调试工具的LOCAL定义。这里也应该通过FORK_PROCESS语句来启动相应的驱动和支持任务，在相应的程序员手册中有详细描述。
附录A：TCAP设置例程模块ID讯息
说明：
这个讯息为一个指定的TCAP例程设置module_id。当发送任何来自网络上的带有事务id中指定例程的讯息时，TCAP使用这个module_id作为目标节点。
讯息格式：
| 讯息标头 |
|
| 字段名称 |
含义 |
| 类型 |
TCP_MSG_S_TCI_ID （0x5794） |
| Id |
Instance |
| src |
发送module_id |
| dst |
TCP_TASK_ID（0x14） |
| rsp_req |
用于请求确认 |
| class |
0 |
| status |
0 |
| err_info |
0 |
| len |
1 |
参数域
参数描述：
Instance
应该发送至指定module_id的任何接收讯息的事务ID中设置的例程值。
module_id
对于指定例程，module_id用作TCAP发送讯息的目标。
如欲了解更多信息，请访问：http://www.Dialogic.com/
| 