华为端局交换机汇接局数据制作探讨

开篇：润墨网以专业的文秘视角，为您筛选了一篇华为端局交换机汇接局数据制作探讨范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

[摘 要]本文是为实现智能业务，通过增加呼叫源、号首集，利用号首处理和限呼、及修改中继群等方法将华为端局的话务上移，全部指向汇接局，即本局的呼叫也指向汇接局从而实现智能业务触发的数据制作的探讨。

[关键词]CENTREX；呼叫源；中继群；号首集；号首处理；目的码限呼；字冠；

一、前言

全网智能化业务在各运营商中发展迅速，要求市话端局呼叫都指向汇接局，实现智能业务触发，通过智能数据的制作，现在将铁通大兴安岭分公司的华为32MCC08交换机实现的方法以及实现过程中遇到的问题做分析。 具体要求：

1.端局的所有呼叫都指向加格达奇汇接局，即本端局内部的呼叫也需要先指向汇接局，再由汇接局指回本局时才接通。

2.目前要求用户的计费和呼叫方式不变。

3.端局的CENTREX群用户短号互拨还是端局内部交换，不上汇接局。

二、实现原理

华为32M端局交换机下挂的所有用户拨打的原号首集0中的字冠都得指向CC08128M汇接局，在汇接局中增加端局的细字冠，并把这些字冠设置成“触发SHLR”，路由选择码再指向华为端局进行落地，这样原端局内部的呼叫先上移到汇接局进行触发省公司智能平台后，返回本端局，实现彩铃、混合放号等智能化业务，而对CENTREX群用户内部拨打，是不需要出群进行话务上移，CENTREX用户拨打短号的呼叫流程如下：先查询长短号对照表，得到对应的长号，然后根据长号在被叫号码分析表查找字冠，进行字冠分析。当字冠有号首处理数据时，有软件参数来决定该号首处理是否起作用。呼叫内部参数4比特4设置为1：主机根据长号进行分析和接续；呼叫内部参数4比特4设置为0：根据长号进行分析接续，在号码分析过程中，不进行号首处理，即使配置了号首处理的数据，交换机也不进行号首处理。 但CENTREX用户拨群内用户的长号、紧急出群字冠、广域CENTREX虚拟接入码等，直接按被叫号码分析表进行分析，不受此软件参数影响

三、实现方法

在新号首集中新增字冠数据。在华为端局新增号首集1，在号首集1内，增加现有号首集0内的所有字冠，并把“业务属性”为“本局”的字冠，在号首集1内的“业务属性”都做成“本地”，路由指向加格达奇汇接局，其他属性同号首集0。因为端局内部铁通字冠比较单一，为了简化数据，在号首集1中只做了8一个大字冠，业务属性做成“本地”，路由指向汇接局，其他属性同号首集0。增加一个字冠的命令如下： ADD CNACLD P=2， PFX=K’8 ，RSC=5.

针对不同呼叫源进行不同的呼叫处理。在端局内，要求汇接局入局中继群的呼叫源与本局用户呼叫源分开。原端局没有实行智能业务时，入中继的呼叫源和本局用户的呼叫源为一个0，为实现入中继和本局用户对同一字冠的不同处理，新增呼叫源码1，属性同呼叫源码0，并在入中继群上修改呼叫源码为1，本局用户的呼叫源0对号首集0内的“业务属性”为“本局”的字冠做号首处理，变换到号首集1内重新分析，按照上步，数据可以送到汇接局了。 但对于汇接局的入中继群所在的呼叫源，不做号首处理，所以汇接局入局的呼叫就可以直接落地到本局了。

四、问题解决

问题1：长短号相同的CENTREX群如何实现群内呼叫不上汇接局

本端局CENTREX用户号码因为比较有规律 ，而且这些CENTREX用户所在的号码连续而且比较整齐，所以对本端局CENTREX用户做群字冠处理，如果能匹配到出群字冠，就直接出群，到“被叫号码分析表”进行分析了。如果“出群字冠描述表”没有匹配到记录，再查“CENTREX号码分析表”，这个表是按照最大匹配进行的，如89800做成“群内”，9做成“出群”，用户拨8980088时是按照“群内”字冠进行分析的。使用“出群字冠描述表”的好处是可以控制“是否听二次拨号音”、“是删除出群字冠”。

问题2：对于某些用户只有本局权限的情况

例如，某一类用户只有本局权限没有本地权限，但所以呼叫都送汇接局后，其权限必须修改成“本地”，但这时这类用户就可以拨通所有“本地”字冠，也可能造成纠纷。由于32MCC08交换机版本只有“业务属性”，没有“业务权限”这个域，所以要达到此目的，只能先放开用户的“本地”权限，然后利用限呼数据代替“本局”的权限。具体的限呼数据就需要根据本局具体的数据来作了。只对本地的他网用户的字冠进行限呼即可，在首号集0中即被限制，数据还是比较简单的。但是这样的数据会给自动停复机、放号、增加本局字冠等其他日常维护工作变得复杂，需要提前通知局方。增加一个目的码限呼的命令为：SET DSTCLMT

问题3：对存在限呼的用户进行处理

在号首集0里已经有限呼组的用户，在进行号首处理时，会出现到号首集1中拨打不通的现象，原因为限呼字冠到号首集1中被限制。例如：用户限呼组为5，目的码允许字冠为89号首集为0，在被叫字冠进行号首处理时，需在限呼组5中增加目的码允许字冠89，号首集为1，这样才能实现被叫字冠平移到号首集1中时，达到呼叫允许接通。

五、其他注意事项与启发

1.号首集1内的数据，可以做成2-8的大字冠，但是条件是本局用户所在字冠的计费选择码都是一致。否则就需要按照计费选择码来进行细化字冠。

2.如果局方有针对本局用户所在字冠的话务统计，需要考虑号首处理和号首集1的影响。

3.中继群与本局用户的呼叫源分离时，需要考虑与呼叫源相关的已有数据：主叫分析、号首处理、主叫甄别、中继承载、失败处理、补充信令等，不能遗漏数据造成呼叫故障或者来显问题。

4.原来号首集0内已有的号首处理、主叫分析、中继承载数据，需要考虑是否牵涉到本次针对本局用户所在字冠的号首处理数据。如果有，需要考虑到这些数据与本次号首处理之间的影响。特别需要考虑“变换后不重新分析”的情况，可能有的需要重新做数据来实现，有的则需要在号首集1内补充数据才能实现。

5.原来号首集0内已经有的限呼数据，也需要分析是否涉及本局用户所在的字冠，可能需要在号首集1内补充数据。因为呼叫能到达号首集1的，已经经过前面的限呼流程，在号首集内1我们只需要放行即可。若号首处理变换了号首集，则目的码限呼/允许会同时按变换前和变换后的号首集来查限呼表，但目的码始终是按所拨号码来分析，而不会按变换后的号码来分析呼叫允许，所以对于存在号首集变换的字冠设定的目的码限呼/允许，必须在最初的号首集和最终的号首集里将用户拨打的字冠设置成用户允许，否则呼叫这个字冠还是不成功的。如果只有目的码限呼，就不需要再新增数据。总之，拨测表一定要求详细。

6.由于32M端局局内呼叫送到加格达奇汇接局，所有端局与汇接局间的电路需要根据话务量扩容。需要提前做话务统计，得到本局局内的话务量，来决定本次需要扩容的中继数量以及具体单板与物料。

7.模块内呼叫（SM、SM2、RSM2）呼叫也需要绕到汇接局，对于SM2、RSM2与上级的电路需要根据话务量进行扩容，SM如果有巨大话务的话则有可能需要新增SM模块来割接本SM模块的用户。总之，需要提前分析话务准备物料。

8.因为局内呼叫都上了汇接局，当本局与汇接间电路、链路出现全阻时必然出现本局内部通话也全阻，我们需要对这种情况做容灾方案。方法是：在号首集1内将本局号段复制一遍；并增加2-8大字冠，属性是“本局”；然后利用“无可用电路”做失败处理将号首集0内的字冠变换号首1重新分析即可。对于某个模块与AM中断，要求内部通话不受影响时，同样需要做“无模块间电路”失败处理来实现容灾。

六、结束语

智能业务是未来交换发展的趋势，智能业务的数据制作与维护也是一项长期的任务，工作量也非常大，故障处理比较复杂，涉及的范围非常广，只有在充分实践的基础上，不断地探索、总结，才能提高业务处理能力和细化数据管理，提供更多、更好的通信服务，才能更好地为通信市场打好坚实的基础。