在ＳＣＣＰ中也存在环路现象，而且它是一种与ＭＴＰ环路无关的环路（即使ＭＴＰ中无环路，也不能解决ＳＣＣＰ的环路问题），参见图3 。
;;;;
图3为典型的移动信令网络图，其中的1、2、3、4均具有ＳＴＰ功能且全部信令点具有ＧＴＴ（Ｇｌｏｂａｌ Ｔｉｔｌｅ Ｔｒａｎｓｌａｔｉｏｎ）功能，Ａ的ＧＴ为Ｔａ，Ｂ的ＧＴ为Ｔｂ，Ａ的点码为ＰＣａ，Ｂ的点码为ＰＣｂ，依此类推 。为了简化问题，先分析消息从Ａ到Ｂ的情况（Ｂ到Ａ也类似） 。假设点Ａ、点1、点2到Ｂ点ＧＴ路由表做成如下方式：
信令源点被叫ＧＴＧＴＴ结果
ＡＴｂＴｂ的ＧＴＴ为ＰＣ1或ＰＣ2，ＧＴ＋ＳＳＮ寻址
1ＴｂＴｂ的ＧＴＴ为ＰＣ3或ＰＣ2，ＧＴ＋ＳＳＮ寻址
2ＴｂＴｂ的ＧＴＴ为ＰＣ4或ＰＣ1，ＧＴ＋ＳＳＮ寻址
（注：ＩＴＵ规定ＳＣＣＰ的ＧＴ翻译结果最多只能两种）
Ａ和Ｂ之间有ＳＣＣＰ层的信令关系，当有一消息从Ａ发往Ｂ，按上面的路由表，有可能存在如下形式的翻译：被叫Ｔｂ在Ａ中的ＧＴＴ结果是点1并且根据ＧＴ再选路由；消息到达点1后、点1对Ｔｂ做ＧＴＴ，ＧＴＴ结果是点2并且根据ＧＴ再选路由；消息到达点2后、点2对Ｔｂ做ＧＴＴ，ＧＴＴ结果是点1，这时候ＳＣＣＰ的环路就出现了，因为消息包在点1、2之间出现了转发 。究其原因，是点1和点2对别的区域内的ＳＰ的ＧＴ翻译有误而引起 。我国移动信令网络较大，其中包含的各省市的ＧＴ（用户ＭＳＩＳＤＮ、ＭＳＣＩＤ、ＨＬＲＩＤ等）较多，ＧＴ翻译做得不正确、不准确，就有可能出现环路或者信令包要被多次转发而造成延迟 。另外，假如ＳＣＣＰ的翻译不合理、数据翻译不完全也将造成环路，下面为一实例 。某地市的关口局做开局调测时的网络结构见图4 。
;;;;
当时的ＧＴ路由表被做成如下形式：
信令源点被叫ＧＴ ＧＴＴ结果
ＧＭＳＣ所有ＧＴ所有ＧＴ的ＧＴＴ为ＰＣ1或ＰＣ2，ＧＴ＋ＳＳＮ寻址
ＨＬＲＴｇｍｓｃＴｇｍｓｃ的ＧＴＴ为ＰＣｈｓｔｐ1或ＰＣｈｓｔｐ2，ＧＴ＋ＳＳＮ寻址
ＨＳＴＰ1ＴｇｍｓｃＴｇｍｓｃ的ＧＴＴ为ＰＣｇｍｓｃ，ＧＴ＋ＳＳＮ寻址
ＨＳＴＰ1ＴｈｌｒＴｈｌｒ的ＧＴＴ为ＰＣｈｌｒ，ＤＰＣ＋ＳＳＮ
ＨＳＴＰ2ＴｇｍｓｃＴｇｍｓｃ的ＧＴＴ为ＰＣｇｍｓｃ，ＧＴ＋ＳＳＮ寻址
ＨＳＴＰ2ＴｈｌｒＴｈｌｒ的ＧＴＴ为ＰＣｈｌｒ，ＤＰＣ＋ＳＳＮ
由于ＧＭＳＣ是信令端局，所以开局人员将它的ＧＴ路由表翻译做得很粗，这样包含了所有ＧＴ（包含了所有的ＭＳＩＳＤＮ号段），想是今后不再做任何数据以减轻今后维护量 。但是由于该数据也将ＧＭＳＣ的ＧＴ送到ＨＳＴＰ翻译（漏洞就在于此） 。假如ＧＭＳＣ始发一消息ＳＲＩ，按上述路由表，ＧＴＴ结果为ＰＣｈｓｔｐ1或ＰＣｈｓｔｐ2，到ＨＳＴＰ1或ＨＳＴＰ2后，将Ｔｈｌｒ翻译成Ｐｃｈｌｒ且按ＤＰＣ＋ＳＳＮ选路将顺利到达ＨＬＲ，发出消息没有问题；当ＨＬＲ返回ＳＲＩ ＡＣＫ消息时问题出现了，按路由表到达ＨＳＴＰ1或ＨＳＴＰ2且按ＧＴ＋ＳＳＮ（ＧＭＳＣ的ＧＴ）选路由，到达ＧＭＳＣ后，由于是按ＧＴ选路，路由表中ＧＭＳＣ将所有ＧＴ翻译到ＨＳＴＰ，这时候环路产生了，消息不停地在ＨＳＴＰ和ＧＭＳＣ之间转发，造成呼叫无法进行 。通过仪表分析，发现了该问题 。解决办法是要求端局将自己的ＧＴ指向自己（纠正错误的ＧＴ翻译结果），同时ＨＳＴＰ将翻译结果按ＤＰＣ＋ＳＳＮ寻址（将ＧＴ翻译结果做完全，这样ＧＭＳＣ不再做ＧＴＴ，可以减小信令延迟），环路情况才得以解决 。由此可见，ＧＴＴ结果正确与否、ＧＴＴ结果完全与否是引起ＳＣＣＰ环路的根本原因 。
推荐阅读
- 中国移动APP中办流量具体操作方法
- 领先移动影像 引导时尚生活
- 移动新号段195新增1亿号码资源 电信获批193号段
- 安卓手机移动数据打开没反应处理操作过程
- 快图浏览不能删除移动照片怎么办
- GPRS开启移动多媒体通信大门
- 快用苹果助手移动客户端下载安装应用
- vivoz5微信怎么开启指纹支付
- 聊一聊我的LG G635
- 移动LG118入手感受