[ page1 ] [ page2 ]

摘要
介绍
概念
　双MTP3概念
　MTP上的状态机
　双电话操作（基于CIC）
　双SCCP（子系统状态维护）
　双TCAP操作
　TCAP 用户(GSM-MAP、IS41-MAP、INAP)
设置
　MTP3的设置
　ISUP和TUP的设置
　SCCP的设置
　TCAP的设置
机箱间通信
容错应用
设置system.txt值
　主机协议实现的system.txt
　信令处理器板卡协议实现的system.txt

■ 摘 要

　　在使用Dialogic NetStructure SS7设备的SS7环境中，为了得到"五个9"有效性和提高容错能力，可以将一个SS7信令端点扩展在两个机箱上。通过SS7节点在多个机箱上应用可以将信令点的功能分离，将多机箱内的硬件处理器相互独立出来，在一个处理器发生故障的情况下，另外一个处理器还能够继续工作，整个系统还可以正常运行。

　　Dialogic NetStructure SS7设备就是为这种双处理器结构设计的，它提供了一种将一个节点的编码器分散到两个SS7协议引擎上的结构。使用这种技术，只要在分离的两个机箱中同时安装Dialogic NetStructure SS7信令卡，一个SS7链路集内的链路就可以分散在这两个机箱中处理。这种双机箱应用具有高可用性和高容错力的优点，本文讨论这种双机箱方案的设计与应用，

■ 介　绍

　　因为公众电话网用户对于业务可靠性的期望日益增高，对设备生产商和系统集成商提出了高容错能力和高可用性的要求。常常使用'五个9'来表示可用性（要求系统在99.999%的时间都可以工作）。

　　这种系统即使部分硬件或软件发生故障时，也必须能够继续提供服务。当通信网中的信令设备发生故障时，有许多众所周知的方法来保证系统继续工作：

• 到终点节点建立多条信令通路（SS7链路和链路集）
• 通过独立的接口和电缆来分配这些通道
• 将单信令点对所有SS7信令的处理分配到单个机箱内的多个处理板卡处理
• 为单个信令点提供两个物理上独立的SS7接口（Dialogic NetStructure SIU和SS7板卡）
• 在两个机箱之间划分信令点的功能，包括应用层。（本文的主题）

　　上面所列的前3个方案可以通过在两个相邻的节点之间采用多条链路（64或56Kbps）来实现，最后两个方案可以通过在两个机箱内采用两个独立但互相协作的SS7协议栈来完成。这两个机箱在正常情况下是分开的，但可以通过互连来提供更高的抵抗故障的能力。

图1：双SS7协议容错

　　◎　在多于一个机箱上实现一个SS7信令点

　　在多个机箱上实现一个SS7信令点，将正常的处理器与另一个故障的处理器分割开，使整个系统在一个处理器或机箱完全故障的情况下可以继续提供服务。与通用的故障容错的结构相同，有许多方法来实现这种设置，每种方法都有优点和缺点。

　　Dialogic NetStructure SS7信令卡采用一个2N通道并且能够将节点编码分布在两个当前的SS7协议引擎上。这允许一个SS7链路集中的连接分布在两个独立的机箱中，每个机箱中都安装了SS7信令卡。

　　系统的两部分之间需要提供两条通信路径，一条在MTP层，使用MTP2数据链路作为传输协议，另一条在第4层或User Part层，在两部分的第4层协议之间传送进程间的消息。第二条通路通常通过使用Dialogic提供的TCP/IP Ethernet和RSI（Resilient Socket Interface）软件完成。这种组合提供一个SS7接口，协议处理分散在两个物理上独立的机箱中，而在网络上象一个整体。

　　框图（图1）中描述了双系统的协议之间的关系。

　　同时也需要考虑维护状态信息，并且检测应用层的指示，这些内容在本文的后面部分讨论。

图2：正常路由状态

图3：到MTPA的连接全部故障时的状态

■ 概　念

　　◎ 双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，并在可用的链路上发送，如图3。

　　MTP A和MTP B之间的链路的设置方法与其他任何SS7链路和链路集相同。如果有额外的数据设置表明此链路与其他连接相邻节点的链路不同，应区别对待。

　　每个MTP接收的消息总是传送到本地第4层协议上。假设本地User Part总是可用的。

　　◎ MTP上的状态机

　　SS7协议的第4层为每一呼叫或事务处理维护状态信息。有两种可能的方法：一种方法是将状态信息复制到组成信令点的N个系统中，第二种方法是分割数据，使每一半状态数据存贮在系统的对应部分中，这样任何一个子机架发生故障都会使系统容量减少1/N。

　　第一种方法需要一个可靠的在容错系统的N个部件间复制状态数据的解决方法，如果这N个系统使用大量CPU时钟来同步，则这种方法效率低。

　　因为复制过程中故障可能发生在任何节点，很难保证所有的系统都包含相同的数据，所以这里采用第二种方法。

　　◎ 双电话操作（基于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协议来处理。因此在这种情况下，如果两个系统都不识别该信息，就可以防止该信息不停的在系统之间传来传去。

　　此过程如图4所示。

图4：双ISUP操作

　　尽管RSI和TCP/IP方法可能是最简单的，但是消息通过一个依赖于应用程序的机制从一个系统传送到另一个系统。

　　SIU通过从媒介处理中使用以太网分离SS7接口来处理容错的问题，两个SIU作为一个节点编码进行容错，如图5所示，通过分离SS7接口，SIU也允许系统最多可以由32个处理语音电路（媒介）的应用节点组成。

图5：SIU方法

　　◎ 双SCCP（子系统状态管理）

　　SCCP通过支持可寻址的子系统概念提高了消息传递部分（MTP）的路由能力。所有已知的本地和远端子系统的路由可用性（允许状态或禁止状态）在SCCP层中进行管理。在一个由N个SCCP层（或多个SCCP的实例）组成作为同一节点编码的系统中，用户应用程序和远端节点需要能够通过任何SCCP实例交换SCCP数据消息，并且希望每个SCCP中的路由表都是相同的。为了达到这个目的，需要使用广播机制增强SCCP层，这种机制将本地或远端的路由状态的任何改变发送到广播任务。广播任务负责将路由变化传送到N－1（其他）SCCP实例。在双系统中，广播任务只是另一个SCCP层，这两层使用基于消息的API进行通信。在一个双机箱/子机架环境中，这些消息可以由RSI和TCP/IP组合来传递。

　　SCCP总是将接收指示传递给同一机箱的SCCP用户任务。参见图6。

图6：双SCCP操作

　　◎ 双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的module_id为0x24（从B方视为远端TCAP）。

　　每个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。

图8：TCAP用户处理

[ 全文英文版 ]

[ page1 ] [ page2 ]


融合通信专栏>>技术开发>>