網絡智能化過程中端局配合NGN數據設置實例

摘 要：雖然網絡智能化有不可否認種種優點，但在嫩江網絡智能化割接過程中，也遇到了不少問題，通過端局數據設置的全力配合，終于在規定時間內實現全網智能化。

關鍵詞：網絡智能化 中端局配合NGN數據設置 交換機

中圖分類號：F4 文獻標識碼：A DOI：10.3969/j.issn.1672-0407.2013.01-02.003

網絡智能化

* 通過統一的業務提供層（ENIP）以用戶為中心快速提供業務；

* 通過SHLR構建多網集中的用戶數據管理，提供統一用戶管理和認證；

* 通過協議修改和適配，接入層支持對SHLR的訪問，對于端局不支持情況，通過匯接局適配，屏蔽端局特性差異，解放網絡能力；

* 通過業務、網絡、終端及全流程的支撐系統的配合，形成端到端的快速業務響應流程；

* 全網集約控制，方便進行全網話務統計、控制和分析，大大提高了網絡的運行質量；

* 網絡結構簡單、路由簡化使維護工作方便快捷，大大縮短了修改網絡數據及排除障礙的時間；

* 端局模塊化，端局的路由及數據簡單，降低端局維護難度，節省維護人力。

雖然網絡智能化有以上不可否認的種種優點，但在嫩江網絡智能化割接過程中，也遇到了不少問題，通過端局數據設置的全力配合，終于在規定時間內實現全網智能化。

下面談談08交換機割接至NGN網絡所遇到的問題和解決辦法。

案例1：CC08交換機和NGN的SOFTX3000同屬華為的產品，在割接前，認為割接應是沒有問題，事實并非如此，由于嫩江08交換機所帶的用戶有集團和酒店用戶，所以，為了實現集團虛擬網內的部分用戶顯話務臺號碼，分別設置了呼叫源，做主叫號碼分析，進行號碼變換，幾乎每個集團都有一個呼叫源。由于本局話務要強制出局，就要對每個呼叫源呼叫本局字冠進行號首處理，200個呼叫源對應5個本局字冠就是1000條數據，每增加一個呼叫源，需做5條號首處理數據，每增加一個本局字冠，需做200條號首處理數據。其他類型交換機并不需要做那么多數據是因為只有一個源。參考省內其他本地網的割接方案，就是分析到每個呼叫源對應本局字冠，做號首處理的，原因是呼叫源不多。咨詢過華為公司服務熱線，沒有更好的辦法。但在一次測試過程中，對呼叫源采用了65534通配符，問題一下就解決了。

A）將所有本局用戶的呼叫源針對本局字冠進行號首特殊處理。

ADD PFXPRO： PFX=K'8707， CSC= 65534， DDC=TRUE， DDCX=0， NPS=10， RAF=TRUE；

這樣處理對以后數據設置帶來方便，每增加呼叫源，不用做號首處理數據，每增加一個本局字冠，只用做一條號首處理數據就夠了，數據設置大為簡潔，以利今后的維護。

案例2：這樣的數據設置帶來一個故障，酒店用戶經話務臺轉分機無應答重入故障。經信令跟蹤分析，原因如下：

從NGN過來的TG1234，呼叫源為50，號首集為50。

B） 新增號首集50，開放所有本局字冠，業務屬性和業務權限均為本局。

ADD CNACLD： P=50， PFX=K'8， MINL=8， MAXL=8， CHSC=1；

C）對號首集50中的所有本局字冠和PRA用戶新增號首處理記錄，變換為普通號首集0或專網號首集，注意不能重新分析，變換后直接查找號段表實現呼叫落地；

ADD PFXPRO： P=50， PFX=K'8707， CSC=50， DDC=TRUE， NPS=0， RAF=FALSE；

50呼叫源經過號首處理后，存在于0號首集中（這同一個號首集有許多呼叫源，而一個呼叫源只能是一個號首集矛盾，做了號首處理后，同一呼叫源可以在不同的號首集中）。分機無應答重入回的是話務臺的長號，呼叫源為50，因為前面做了65534通配符，所有的呼叫源打本局字冠上NGN，這樣就會再上NGN，這就需要：

D）對0號首集中50呼叫源針對本局字冠進行號首處理，不變號首集，不重新分析。

ADD PFXPRO： PFX=K'8707， CSC=50， DDC=TRUE；

這條數據的設置解決本地來話呼叫源為50的主叫不上NGN。解決無應答重入故障。

案例3：某酒店分機經話務臺轉接，酒店接口機上話單割接前是話務臺的邏輯號87068888，割接后是話務臺的短號，這是因為割接前話務臺號碼變換是在端局，而割接后，號碼變換在SHLR。用戶要求強烈，數據進行重新設置：

1.在SHLR中采用新邏輯號碼對應新物理號碼，老邏輯號碼對應新物理號碼的方法。

例如：話務臺號碼為87030888，路由號為817。

話務臺對外顯示87668888，原路由號為814。

新對應方法 87030888 81787030888

87668888 81787668888

2.在端局做87668888字冠的號首處理，變換成87030888接通。

配置實例：

端局上SS數據1 ） ADD CALLSRC： CSC=1， CSCNAME=\"xx酒店\"， PRDN=3；

2）ADD DNC： DCX=1， DCT=MOD， DCL=8， ND=K'87668888；

3）ADD CNACLR： PFX=K'*65534#， CSC=1， CID=K'8703， RSSC=0， FSC=0， RCHS=0， RUT=ALL， RDCX=1；

SHLR上數據：

1）ADD USR： DN=\"87030888\"， LRN=\"8178703088

8\"；

2）ADD USR： DN=\"87668888\"， LRN=\"8178766888

8\"；

它局號碼在端局的落地數據

1）ADD CNACLD： P=50， PFX=K'87668888， MINL=8， MAXL=8， CHSC=0；

2）ADD DNC： DCX=2， DCT=MOD， DCL=8， ND=K'87030888；

3）ADD PFXPRO： P=50， PFX=K'87668888， CSC=50， DDC=TRUE， NPS=0， RAF=FALSE；

這樣數據設置后，卻再次出現話務臺無應答重入故障。經跟蹤分析，話務臺重入時 ，被叫號碼里邊填充了用戶所撥號碼，而并沒有填寫經過變換后的被叫號碼。

首先在50號首集里邊分析被叫號碼87668888，變號首集為0，號碼為87030888（話務臺的真實號碼），并接續到話務臺。話務臺拍叉至群內用戶B，B用戶無應答重入話務臺，重入時只是將被叫號碼填充為87668888進行分析，這里并沒有變換號首集為50。在0號首集里邊因為沒有87668888，沒有該用戶導致分析失敗，呼叫被拆除。

它局用戶號碼在08交換機落地的，無應答重入時又返回的用戶所撥號碼，即87668888。應做如下數據：

ADD CNACLD： PFX=K'87668888， _SR_39=1， MI

NL=8， MAXL=8， CHSC=0；

ADD PFXPRO： PFX=K'87668888， CSC=50， DDC=

TRUE， DDCX=1， NPS=0， RAF=TRUE；

案例4： 智能公話用戶正常呼叫時，因在被叫前插96544C，發送到SS時不能將C及以后的IAM消息轉發到端局，直接向端局發送REL消息，原因值為非法號碼。

08交換機下掛智能公話，因為08交換機局發送的IAM消息C字冠是后續發送到SS，SS默認對C字冠的處理為“#”符合，對于SS來說（A至F）這些字符雖然可以正常透傳，但是C字符和F字符很特別，C字符是默認為“#”字符，F字符默認為“結束號”進行處理。

將08交換機局的965449字冠最小位長更改為8位后，能正常接續。

案例5 ： 08交換機端局ISDN用戶打本地網用戶，被叫用戶來電顯示為ISDN用戶的物理號。在SS跟蹤信令，發現08交換機端局ISDN用戶送過來的主叫用戶類別為國內號碼，并帶區號。在08交換機端局跟蹤，主叫用戶類別同樣為國內號碼。這樣，帶區號的主叫號碼在SHLR中找不到與此對應的邏輯號碼，所以在被叫端顯示的是ISDN用戶的物理號碼。

修改08交換機軟件參數。呼叫內部參數3， 比特3：ISDN送主叫號碼參數。

=1：送給CCB的主叫號碼是國內號碼；

=0：送給CCB的主叫號碼是用戶號碼。

MOD SFP： ID=P51， VAL=\"FFF7\"；

修改后，被叫端顯示正常。

案例6 ： 08交換機端局本局以及出局話務割接至SS后，根據端局數據簡單化的原則，字冠不必細分，但是，某證券公司要實現限額限呼功能。字冠必須細分，對區內和區間字冠要區分，對港澳臺和普通國際字冠要區分，普通國際和美國字冠等地區要區分，各種類型字冠對應不同的計費選擇碼，對應不同的計費情況和費率，才能使用戶準確地使用限額限呼。

以上案例我認為就是端局配合NGN數據配置比較成功的范例。有一定的推廣價值。

如果以為端局割接至NGN網絡后，端局數據簡單化，一切問題交給SS或SHLR解決，那是錯的。華為的NGN產品，是新產品，有其不成熟之處，除了文章開頭提到的各種優勢以外，并不能解決所有問題。案例1需要SHLR中要實現多個物理號對應一個邏輯號，案例3酒店用戶話單顯示需要與割接前的一致性，案例4是NGN網絡本身的問題，需要打補丁解決。案例5是網絡智能化后，對端局主叫要求規范化。案例6是用戶要實現特殊新業務功能，NGN網絡并不能滿足。這樣集團用戶和酒店用戶提出的各種各樣的需求，有時還需端局實現。這就是網絡智能化和用戶需求個性化之間的矛盾，這種矛盾就需要我們維護人員去解決。在給用戶提供精品網絡的同時，盡量使用戶感到電信網絡的一致性，贏得用戶的信任，才能贏得市場。